A cutover plan turns a completed replacement into a controlled production change. It states when the old SaaS product stops accepting some or all new work, how final data moves, when integrations change direction, and who decides that the new system is ready for users. It also preserves a clear route back when acceptance criteria are not met.
What the plan coordinates
Cutover joins technical and operational activities that have different owners but must happen in a fixed order. Account closure is rarely the first step. Data, interfaces, user access, support, communications, and retained history all need an agreed transition point.
| Workstream | Cutover activity | Completion evidence |
|---|---|---|
| Data | Freeze changes and complete the final transfer | Reconciled migration results |
| Integrations | Redirect interfaces, jobs, and credentials | Successful monitored transactions |
| Access | Enable destination roles and restrict the source | Approved access checks |
| Operations | Start new procedures and support coverage | Business acceptance scenarios |
| Communication | Tell users when and how work changes | Sent notices and support contacts |
| Exit | Preserve archives and schedule account closure | Confirmed retention and vendor steps |
The sequence depends on whether the systems can exchange updates during transition. If they cannot, the plan needs a defined freeze window. If they can, synchronization rules must identify which system accepts writes and how conflicts are prevented.
Decision points in the timeline
A runbook lists tasks. A cutover plan adds authority and evidence to that list. Every irreversible or time-sensitive step needs a named owner, prerequisites, expected duration, completion check, and escalation path.
The main decision points are:
- Ready to start: trial migration, access, support, communication, and data validation criteria are approved.
- Ready for final load: the source freeze or synchronization state is confirmed and outstanding work is accounted for.
- Ready to open: critical data, integrations, permissions, and user scenarios pass their checks.
- Continue or reverse: issues are compared with the triggers in the rollback plan.
- Ready to close the source: retained history is accessible, open exceptions have owners, and contractual exit steps are complete.
Time estimates in the plan support coordination, but the decision gates depend on evidence rather than the clock alone. A delayed check can move the next step. It must not be marked complete merely to preserve the schedule.
Cutover methods for SaaS replacement
Different workflows can use different transition methods. A direct cutover stops work in the source and begins it in the destination after a final migration. A staged cutover moves a bounded user group, location, workflow, or dataset first. A parallel run keeps both systems available for a defined comparison period.
The selection depends on factors such as:
- Write behaviour: whether both systems can safely receive changes without creating conflicts.
- Migration repeatability: whether the final transfer can be rehearsed and completed within the available window.
- Integration boundaries: whether connected systems can switch independently or must change together.
- Operational criticality: what interruption or incorrect processing would mean for the business.
- Fallback limits: how long the source remains usable and how new destination records would be handled after reversal.
After the switch
Cutover does not end when users can sign in. The plan includes a stabilization period with monitoring, support ownership, issue triage, and checks on the first real transactions. It states which exceptions block normal operation and which can enter a managed backlog.
The cost of switching systems includes this temporary overlap and support work. A controlled transition ends when the replacement performs the required work, connected systems behave as expected, users know the new procedure, and the old product has a documented retirement state.
