How do I keep a workspace migration log that helps resolve missing items?
Quick answer
Keep one shared log with a row for each migration batch and a separate, linked record for each exception. Record the source and destination, batch identifier, item counts or other agreed checks, unresolved mappings, verification results, owner, next action, and status. Update it as work happens, and close an exception only when the expected item is located or an agreed resolution is documented.
The question, the details, the next step.
What should a migration log capture so we can find missing workspace items later?
Use the log to answer four questions: what was included, where it was meant to go, what check was performed, and what still needs attention. Give each batch a unique ID, then record its source workspace or area, destination, migration window or date, responsible person, and a brief scope description. Add the expected and observed counts or another check your team has agreed is useful; label each clearly so nobody mistakes a target for a result.
Keep exceptions visible rather than burying them in a general notes field. Record a missing item, uncertain mapping, or failed check as its own issue linked to the batch. A simple status such as Open, Investigating, Resolved, or Accepted for follow-up makes unfinished work easy to spot. Treat these as suggested labels, not a required system.
How do I record a mapping that is unclear, or an item that seems to be missing?
Create one exception record per issue, even if several issues came from the same batch. Include an exception ID, linked batch ID, item name or a safe internal reference, source location, intended destination, issue type, what you observed, and what you have checked so far. If the mapping is uncertain, write the possible destination and mark it as unconfirmed instead of quietly choosing one.
For example, using hypothetical placeholders: EX-014 | B-03 | item: [workspace reference] | source: [team area] | intended destination: [unknown] | type: mapping unclear | observed: not found in expected destination | checked: [locations checked] | owner: [role or name] | next action: confirm mapping | status: Open. This records a lead without claiming the item is definitely lost.
What counts as verification, and how should we record a result that is only partial?
Choose the check before the batch runs where practical, and write down what it can and cannot establish. Depending on the migration, a team might compare agreed item counts, inspect a sample, or check that specific expected items appear in the destination. These are examples to adapt to your workspace and process, not guarantees that every kind of content or setting has been checked.
Record the check, date, person who performed it, result, and any limits. For a partial result, be precise: sample checked: [number or scope]; [items] located; [items] still unverified. Do not mark the entire batch complete just because one check passed. Link each remaining gap to an exception with an owner and next action.
Can you give me a reusable layout that keeps batches and open exceptions connected?
Use two simple sections in a spreadsheet, document, or tracking tool. Keep the batch ID in every exception row so you can filter issues back to the relevant work. Adapt the fields to your team’s process:
BATCH LOG
Batch ID | Date/window | Source | Destination | Scope | Expected check/result | Verification method | Observed result | Verifier | Open exception IDs | Batch status | Notes
EXCEPTION LOG
Exception ID | Batch ID | Item reference | Source location | Intended destination | Issue type | Observation/evidence | Checks completed | Owner | Next action | Due date | Status | Resolution/evidence
A worked hypothetical entry might be B-03 | [date] | [source area] | [destination area] | [scope] | [expected check] | [check used] | partial: [result] | [role] | EX-014 | Needs follow-up | [note]. Update the result when you verify it, preserve a short explanation of the resolution, and leave unresolved items visibly open. Avoid putting information in the log that your team does not need to coordinate the move.
A practical checklist
Assign a unique ID to every batch and exception.
Record source, intended destination, and the scope of each batch.
State the expected check separately from the observed result.
Log each missing item or uncertain mapping as a linked exception.
Give every open exception an owner, next action, and status.
Document what verification covered and what remains unverified.
Close an exception only after recording its resolution or agreed follow-up.
A few more useful answers
Should I put exceptions in the batch notes or a separate list?
Use a separate exception list when issues need their own owner, next action, or resolution evidence. Link each row to its batch ID; brief batch notes can summarize the number of open exceptions.
Can a batch be marked complete when some items are still unverified?
Use a status that makes the distinction clear, such as “Partial—exceptions open,” rather than implying every item was checked. Define status meanings with your team so readers interpret them consistently.
What if we cannot identify the intended destination yet?
Mark the mapping as unconfirmed, record the known source and observations, and assign an owner to confirm it. Do not record a guess as a verified destination.