The weekend nobody wants to run twice
Mail, files, servers and workloads moved with a rollback plan, a cutover runbook and someone awake at 3am.
Knowing what you actually have
Every migration that goes wrong goes wrong because of something nobody knew was there — a service account, a hard-coded IP, an application that only one person still uses and cannot name. The audit is not paperwork; it is the thing that prevents the weekend from going badly.
- Full inventory of workloads, mailboxes, data volumes and dependencies
- Application-to-server and server-to-server dependency mapping
- Licensing position established before anything is bought
- Anything that will not move identified early, with an answer for it
- Risk register and rollback position agreed in writing
The target, and how you get there
The destination is chosen against cost, latency, compliance and who has to operate it afterwards — not against whichever cloud we hold the most certifications in.
- Target platform selected against cost, residency and operability
- Wave planning so the riskiest workloads do not move first
- Network, identity and DNS design ahead of the first move
- Coexistence design so both platforms work during the transition
- Success criteria and a rollback trigger defined per wave
Moving it, in waves
Nothing moves in a single leap. Waves are small enough that a problem is contained, and each wave informs the next.
- Pilot wave with a friendly user group before anything at scale
- Bulk data pre-seeded, with delta synchronisation at cutover
- Cutover in a defined window with a named go/no-go decision
- Desktop, mobile and profile changes handled in advance
- Rollback executed rather than discussed, if the criteria are hit
Getting the data across intact
File shares, mailboxes, databases and archives each move differently, and permissions are where migrations quietly lose integrity.
- Permission and ACL mapping validated after the move, not assumed
- Archive and journal data handled to its retention requirement
- Large datasets seeded offline where bandwidth will not carry them
- Checksums and reconciliation reports per wave
- Legacy platform kept read-only until sign-off
The two weeks that decide how it is remembered
A migration is judged in the fortnight after cutover. We staff for that deliberately.
- On-site or dedicated hypercare for the first two weeks
- A single channel for migration issues, separate from BAU support
- Daily triage with the client through the hypercare window
- Documentation and as-built handed to the operations team
- Decommissioning of the old platform only after formal sign-off
Platforms we migrate to and from
Cloud, workspace and data centre
Tell us what you are running today
We will tell you what we would change, and what it would cost. No obligation, and a named engineer on the call rather than an account manager.