How it works
The method is the product. Seventeen gates, every time.
Output standardises the migration method before it scales anything else. The same gates apply to a twelve-user mailbox move and a tenant consolidation.
- DiscoverInventory source, target, users, workloads, dependencies and scope
- SecureSet up controlled project access and credential handling
- ProtectConfirm backup, export or rollback capability
- Extract / ScanProfile source content and identify errors before migration
- MapMap identities, fields, folders, permissions and objects
- CleanResolve agreed duplicates, invalid structures and unsupported data
- TestRun representative test migration
- ReconcileCompare source and target counts and values, and inspect exceptions
- RemediateFix mapping, tooling or source issues
- MigrateRun approved production transfer
- DeltaCapture changes since initial copy where the route supports it
- CutoverSwitch mail flow, domains, users or production processes
- ValidateAutomated and human QA
- AcceptCustomer sign-off
- RevokeRemove temporary credentials and project access
- RetainApply agreed temporary-data destruction or archive rules
- VerifyIssue Migration Verification Report
Gate 17: the Verification Report
The document you keep. It is what makes a migration checkable months later, and what an auditor, a board or a new IT provider can read without taking anyone’s word for it.
- Project summary
- Source, destination, dates, route ID, project owner
- Scope delivered
- What was migrated and what was explicitly excluded
- Source totals
- Users, mailboxes, files, records or other workload measures
- Destination totals
- Equivalent target measures
- Exceptions
- Itemised failed, skipped or unsupported objects and their disposition
- Permissions & identity
- Sample or full validation check according to route
- Cutover validation
- Mail flow, user login, application access and target workflow checks
- Security closeout
- Temporary access revoked, credentials expired and removed
- Temporary data
- Destroyed or retained per the agreed policy
- Customer acceptance
- Named approver and date
Quality rules we do not bend
- No production cutover without a successful test, unless the Technical Lead documents why a test is impossible.
- No “looks fine” reconciliation. We use counts, checksums where appropriate, API queries, logs and sampled user validation.
- Every exception has an owner and a disposition: fixed, accepted, excluded or escalated.
- Higher-risk cutovers require peer review before execution.
- No engineer deletes source data as part of a standard migration. Decommissioning the old system is your decision, made separately.
- Migrations are run remotely, using secured remote access to your systems. We do not attend site as standard; where on-site presence is genuinely required, it is quoted separately at an hourly rate plus travel.