Downtime Decided Before Cutover Night
How many hours will the business actually be down? That's the number every buyer wants confirmed before signing, and the one most IT migration and implementation services quietly guess at. We plan tenant moves and M&A IT integrations backward from a tested rollback point, so the window is fixed on paper before cutover night, not discovered live on it. Already decided where to move? This is where that becomes a dated plan. Still weighing the destination belongs with Virtual CIO, and the wider Advisory team.
Where Most Migrations Quietly Go Wrong Before Cutover Night
A migration rarely fails on the night itself, it fails days or weeks earlier when one of five things wasn’t checked properly. Still deciding whether or where to move at all? That decision sits with Virtual CIO, not here. Once the destination’s fixed, cutover risk comes down to five gaps we check on every project before a date goes in the calendar.
Data That Doesn't Match Once It Lands
A mailbox or dataset can migrate cleanly on screen while the item count on the destination doesn't match the source. Without batch by batch reconciliation, that gap surfaces weeks later.
No Rollback Point Written Down
A verbal promise that a migration can be undone doesn't hold up at two in the morning. Every cutover plan needs a documented rollback point, agreed before the runbook's written.
A Pilot That Never Actually Ran
Skipping the pilot to save a week is the fastest way to find the method's flaws in production. A small, low risk batch moves first and proves the process before it touches every user.
Hypercare That Stops On Go Live
Most real issues surface in the first few days of normal use, not the first hour after cutover. Ending elevated support the moment the move finishes just hands the fire to your team instead of ours.
The Old System Switched Off Too Soon
Decommissioning the source environment on cutover day removes the fallback that made the plan reversible. We leave it live and untouched until hypercare closes clean.
Most migrations don't fail on the big move, they fail on the parts nobody planned for: the mailbox that doesn't map cleanly, the one integration nobody remembered until it broke, the fallback that only gets thought through after go-live weekend has already started. A migration is only as good as the plan for what happens when something doesn't go to plan. We build that in from the start, test the cutover before it's live, and stay through go-live itself, so the project ends when the business is actually running on the new system, not when the migration technically completed.
The Six Steps Every Migration Plan Has To Cover
Executive Solutions runs IT migration and implementation services as a fixed sequence, not a checklist improvised around a deadline. If you’re not yet sure a workload belongs in the cloud at all, start with a cloud readiness assessment first. Once the destination’s confirmed, here’s exactly what happens before we ever set a cutover date.
Discovery
Every system, mailbox, dataset, integration and dependency being moved is inventoried, along with who actually touches each one day to day.
Target State Design
Where each item lands, which tenant, platform, and environment, is fixed in writing before anything moves, so the target doesn’t shift.
The Runbook
The Pilot
A small, low-risk batch moves forward first, proving the method before production data follows.
Batch Reconciliation
Every batch is checked against the source: record and item counts have to match before that batch is signed off.
Hypercare
An elevated support window after go live, watching for issues before your team has to report them.
Four Things You Can Check Before Cutover, Not After
A rollback point only means something if it was tested, not just written down. Before a cutover date is ever set, four things are ready for you to check for yourself. These aren’t generic reassurances, they’re the actual artefacts from your migration: the written runbook, the pilot’s result, the reconciliation report, and the ticket log. Hypercare tickets, once we’re live, are logged and closed through the same 24/7 IT support desk that covers you afterwards, so nothing changes hands on day one.
The Rollback Point
Every migration has a documented rollback point, agreed and tested before the runbook is finalised, not discovered halfway through cutover night.
The Pilot Result
A small batch runs first, and what matched, what didn’t, and what got fixed is shown to you before the full migration is booked to go ahead.
Batch Reconciliation Reports
Each batch is checked against the source system, and the counts have to match before that batch is signed off, so a gap is caught the day it happens, not weeks later.
Closed Hypercare Ticket Logs
Every issue raised during the elevated hypercare window is logged and closed through the service desk, so you can see it was caught and closed, not just promised, and who on our side closed it.
What Actually Sets The Price Of A Migration
There’s no flat per-seat rate here, because the real driver isn’t headcount. It’s four things: system count, data volume, cutover complexity and rollback requirements.
01 System Count And User Volume
02 Data Volume Moving Live
03 Cutover Complexity And Rollback Depth
04 Fixed Price Or Scoped Discovery
Who this is for
This page is for a business working against a fixed deadline: a licence expiring, a lease ending, two companies merging IT after an acquisition, or a platform reaching end of vendor support. Still weighing whether or where to move? That's our virtual CIO services, not this page.
How it works
frequently asked questions
How many hours will we actually be without our systems?
It depends on what’s moving, but the pilot run and staged batch sync before cutover exist to shrink that number and know it in advance, not discover it on the night.
What happens if the cutover needs to be rolled back?
We fix the rollback point, the last moment the move can still be reversed without losing data, in the runbook before we start, and we test it in the pilot rather than guess at it live.
Will we lose any data in the move?
No. Every batch is reconciled against the source, record counts checked and matched, before it’s signed off and the next batch runs.
When does the old system actually get switched off?
Not on cutover night. We keep it live as a fallback until hypercare closes clean, then decommission it and hand ongoing oversight to Proactive Monitoring & Management.
Know Your Downtime Number Before You Ever Book The Cutover Date
Book your migration discovery call.