At a glance:
The gap between signing and setting a cutover date is where most migration friction lives
A dependency audit against documentation is always incomplete. Run it against production traffic logs, including off-hours patterns
DNS TTLs set at 3600s flush within the hour. Lower them to 300s at least 48 hours before your cutover date.
The rollback threshold needs to be a specific agreed number, defined before cutover day. Without it, the decision happens by committee at 2 am when everyone is tired
The migrations that go smoothly are the ones where the open items were known and on a plan before the cutover window opened
The gap between signing and setting a cutover date is where most migration friction lives. The technical blockers surface in the scoping call. What follows are the questions that need clean answers from your engineering lead, CFO, and operations before the plan is set.
Before you set a date
"Is the dependency audit complete, or do we just have a list of things we know about?"
A complete audit covers every runtime dependency, including the services that only surface under specific traffic patterns or at off-hours, not just the ones your team documented when the architecture was fresher. Run the audit against production traffic logs. Documentation is always out of date.
"Have we lowered our DNS TTLs?"
Lower your records to 300s or less at least 48 hours before your cutover date. When you flip DNS, traffic moves to the new environment within minutes instead of trickling over for up to an hour, so you're not left supporting a slow tail of users still hitting the old one.
"What's the rollback decision point?"
Do you have a specific, agreed threshold where the team calls it and goes back if traffic in the new environment isn't clean?
Without that number, the decision is made in the middle of the night when everyone is tired, and nobody wants to be the one who made the call. Define the threshold before cutover day, not during it.
"What does traffic validation look like before we flip DNS?"
Synthetic load testing and real traffic patterns are different things. Know which one you're validating against before the window opens, so the team is aligned on what "looking good" means before anyone touches DNS.
"Who's our Servers.com by Nexcess point of contact during the cutover?"
Most teams navigate the cutover window through portal and API access. The prep work is what makes the cutover window quiet. But when you page that contact at 2 am, there's already a prepared team behind them, not a cold handoff to someone starting from scratch.
Depending on your environment, your solutions architect can coordinate infrastructure layer support during your cutover window. Ask about this during scoping.
"Are our monitoring dashboards set up for the new environment?"
Whatever tools your team uses to track uptime, error rates, and traffic should be configured for the new environment before the cutover window opens. Updating dashboards during a live migration is avoidable friction.
After you go live
"Has the old infrastructure been fully decommissioned?"
Double-billing is one of the most common post-migration surprises. Once the new environment is stable, confirm with your team that the old infrastructure is off and the associated billing has been terminated.
It sounds obvious, but in a complex migration, it's easy for a secondary environment or a legacy backup instance to stay running longer than intended.
Verify decommissioning in writing, with a date, so there's no ambiguity when someone reviews the invoice two months later.
"Does the first invoice match what was projected?"
Your CFO signed off on a cost model during the scoping process. The first real invoice is the moment that model gets tested. Pull it against the projection before it lands in a board deck, not after.
Catching those early, while the migration context is still fresh, makes the conversation easier.
"Does the CFO have what they need to close out the old infrastructure cost?"
The first board reporting cycle after go-live should include the new cost structure. Make sure your CFO has documentation of when billing was transferred, how the fixed cost maps to your prior spending, and any prorated periods that need to be accounted for. That package should be ready before the reporting cycle opens.
"Do we know who to call after we're live?"
Your solutions architect has a clear handoff to your dedicated account manager before you go live. Configuration questions, capacity adjustments, the conversation about adding a new region: all of it has a known path. You won't be hunting for a contact 60 days in.
