This is a composite story, built from patterns that show up again and again in consulting work, about a mid-sized logistics firm we’ll call Northline and the weekend it moved its warehouse management system to the cloud. The migration itself is not the interesting part. The reason it deserves a write-up: the team spent almost as much effort planning the fortnight after cutover as they spent on the cutover itself. Their post-migration stabilization plan is the reason the following Monday was boring, and boring is exactly what you want after a big move.
The starting point: a team that had been burned before
Northline’s platform team was five engineers led by a pragmatic operations manager, call her Priya. Two years earlier, the same team had moved their order database to new hardware. The cutover went smoothly. The following week did not. A reporting job that ran only on Wednesdays failed silently; a partner integration timed out under real load; and the engineer who had written the migration scripts was on a long-planned holiday. Priya spent that week fielding calls from warehouse supervisors with nobody available who understood the change.
So when the cloud migration landed on the roadmap, Priya opened the planning session with a single rule: “We don’t finish on cutover night. We finish when the system has been boring for a week and the people running it can sleep.”
Planning the main event, briefly
The cutover plan itself was conventional. Freeze changes, sync data, switch traffic, verify, keep a rollback path ready for the first hours. The team rehearsed it twice in a staging environment. That part took about a third of the planning time.
The other two thirds went into the period after the switch. That ratio surprised some of the newer engineers. One of them asked, half joking, whether the team was planning a migration or a holiday. Priya’s answer was that the cutover only had to work once, on one night, with everyone awake and watching. The fortnight afterwards had to work at three in the morning, on a weekend, with whoever happened to be on the rota. That was the harder problem, so it got the bigger share of the effort.
Planning the after: what Northline actually wrote down
A named stabilization window
The team set a two-week stabilization window starting the moment traffic moved. They chose two weeks deliberately: long enough to cover every weekly batch job twice and a payroll cycle once. The dates went onto the shared calendar, into the change record and onto a sticky note on Priya’s monitor.
Reserved people, not “available” people
Two engineers who wrote the migration were taken off new project work for the window. They were not idle. They worked on documentation and small fixes. But their calendars stayed clear enough to drop everything if the new platform misbehaved. Priya also checked leave plans before fixing the cutover date, which sounds obvious and which they had not done last time.
An on-call handover before cutover, not after
Northline’s on-call rota covered several systems, and the people on it were not all on the migration team. Two days before cutover, the migration engineers ran a short handover session with everyone due on call during the window. They covered what was moving, where logs now lived, which dashboards to check first, the rollback steps and, importantly, a phone tree: which migration engineer to call for which kind of problem, day or night. The notes went into the runbook.
The broader shift towards structured incident practice, described in our article on how SRE thinking reshapes the way teams handle incidents, was part of why Priya insisted on that phone tree being written rather than assumed.
A single issue channel with a single owner
Every problem during the window, however small, went into one tagged channel. One engineer per day held the “stabilization lead” role, triaging and assigning. The rotation meant no single person carried the whole fortnight.
Follow-up reviews booked in advance
Before cutover, Priya booked three reviews: the morning after cutover, the end of the first week, and the last day of the window. Each had the same short agenda: what broke, what was fixed, what is still open, and whether to extend the window.
A list of predictable loose ends
The team listed every follow-up job they could foresee: decommissioning old servers, removing temporary firewall rules, tidying migration scripts, updating architecture diagrams, and confirming backups on the new platform had actually been restored once in a test. Each item got an owner and a target date inside or just after the window.
Recovery time for the cutover crew
Cutover was scheduled overnight Saturday. Priya gave the cutover crew Monday off in lieu and arranged cover. Nobody argued.
What happened during the fortnight
Cutover went to plan. On Sunday morning, the first review found two minor issues: a label printer at one warehouse needed a configuration change, and one internal dashboard was still pointing at the old database. Both were fixed by lunchtime.
On Wednesday, the weekly reporting job ran. This was the exact job that had failed silently in the previous migration, and the team had flagged it on their loose-ends list. It ran, but slowly. Because one of the reserved engineers was watching for it, the slowdown was spotted within the hour, traced to a missing index on the new database and fixed before the warehouse managers needed the report.
On the second Friday, the on-call engineer, who was not on the migration team, was paged at night about a partner integration error. She opened the runbook, followed the phone tree, and reached the right migration engineer in minutes. It turned out to be a certificate on the partner’s side. The handover notes meant she could rule out the migration quickly instead of spending hours wondering whether the new platform was to blame.
The end-of-week review recorded six issues in total, all closed. The team agreed the window could end on schedule.
Closing the window properly
At the final review, the stabilization leads walked through the issue channel, confirmed every loose end was either done or scheduled, and formally handed the platform to business-as-usual operations. The on-call runbook was updated to remove migration-specific notes and keep the lasting ones. Old servers were scheduled for decommissioning the following week, after one more backup check.
The team also spent twenty minutes writing down what they would change next time. Their main note: the handover session should have included the warehouse supervisors, not just engineers, because the label printer issue had first been noticed on the floor. That lesson fed into their next roadmap, in the spirit of our guide on laying out a reliability roadmap in stages.
Why the after-period plan worked
None of Northline’s measures were clever. They were ordinary, written down early and actually followed. The difference from the earlier migration came down to a handful of practical decisions:
- The after-period had dates, so nobody had to argue about when it ended.
- The people with context were reserved, so incidents did not start with a hunt for knowledge.
- On-call was briefed before anything changed, so the first night-time page was a short call rather than a crisis.
- Reviews were booked in advance, so they happened even when things looked fine.
- Loose ends were listed with owners, so the platform did not accumulate leftovers.
- The cutover crew got rest, so tired people were not making late decisions in week one.
Fewer surprises translate directly into less downtime and steadier service for users, which our piece on the link between reliability work and user experience explores in more depth.
The same pattern outside IT
Priya later said the idea came partly from a relative who had travelled abroad for treatment and found that the planning service she used, SurgeryPlanet, a medical-travel site for international patients, treated lodging, transfers and aftercare as part of the plan instead of something to work out on arrival. The parallel stuck with her: if the stay afterwards gets organised in advance for something that important, a database migration deserves no less.
A practical template you can copy
If you want to borrow Northline’s approach, add these lines to your next migration plan:
- Stabilization window: start date, end date, reason for the length.
- Reserved engineers: names, reduced project load during the window.
- On-call handover: date of session, link to runbook notes, phone tree.
- Issue channel and daily lead rotation.
- Pre-booked reviews: dates and standard agenda.
- Loose-ends list with owners and dates.
- Rest plan for the cutover crew.
Seven lines in a document. They are what turned Northline’s second migration into a story nobody needed to retell at the next team offsite.