A cloud migration cutover is ready for go/no-go when you can hand an auditor, your risk team or your own board a folder that proves five things: the workload was tested in its new home, the change was approved, a tested rollback exists, data reconciles, and monitoring and recovery work in the cloud, not just on the old servers. If any one of those is “we’ll sort it out after the weekend”, you are not ready to cut over.
Educational only; not legal or regulatory advice. Regulated financial institutions should confirm their own obligations with compliance and MAS-facing teams.
Who this is for, and who should skip it
For: Singapore CIOs, heads of infrastructure, programme managers, risk and audit leads, and the delivery partners working for them, who are moving an application from on-premise or a colocation facility to a public cloud region and need a cutover pack that holds up to questions later. It is written with MAS-regulated firms in mind, but works for any team that wants a clean audit trail.
Skip if: you are still choosing a cloud provider (see MAS TRM questions for fintech software vendors); you are migrating SAP specifically (see the SAP S/4HANA cutover readiness checklist); or you need user-acceptance sign-off for a new build (see the acceptance test evidence pack). This article does one job: what evidence should exist before, during and after the cutover window of a cloud migration.
Why “we migrated successfully” is not evidence
Many cutover problems are not dramatic outages. They are quieter: a batch job that never got re-scheduled in the new environment, a firewall rule opened “temporarily” during the weekend and never closed, logs that stopped flowing to the security team because the new workload was never connected to the central monitoring tool, or an old database switched off before anyone confirmed the archive could be restored.
Each is easy to prevent and hard to explain afterwards. The fix is boring: decide in advance which documents must exist, who owns each, and by when. That list is the evidence pack.
What MAS guidance actually says (and doesn’t)
The MAS Technology Risk Management (TRM) Guidelines (January 2021 PDF) do not contain a chapter called “migration” or “cutover”. That surprises people. What they do contain are expectations that a migration triggers all at once:
- Testing and acceptance (section 5.7): an approved test plan, regression testing for changes to existing systems, major defects addressed before production, and test results documented and signed off by the relevant stakeholders.
- Change management (section 7.5): risk and impact analysis before the change, test results signed off before production, a change advisory board that approves changes, a backup taken before implementation and a rollback plan, and logging enabled during the change process.
- Software release (section 7.6): segregation of duties so no single person can develop, compile and move code between environments, plus traceability of what moved.
- Recoverability (sections 8.2–8.4): recovery time and recovery point objectives (RTO and RPO) aligned to business priorities, disaster recovery tested with service providers where they manage the assets, and backup restoration tested periodically.
Alongside that, the MAS Advisory on Addressing the Technology and Cyber Security Risks Associated with Public Cloud Adoption (Circular MAS/TCRS/2021/03, June 2021) adds cloud-specific points that matter on cutover weekend: the provider secures the cloud but you secure what you put in it; staff who can configure cloud services through the provider’s management console should use multi-factor authentication; infrastructure-as-code should have maker-checker controls, and running infrastructure-as-code and manual changes side by side should be avoided; cloud workload logs should feed your enterprise-wide security monitoring rather than sit in a silo; and workloads are not resilient just because they run in the public cloud.
A cutover pack is these expectations made concrete for one weekend. Unregulated teams can still use the TRM Guidelines as a benchmark.
The cutover evidence pack (the table to copy)
Here is a fourteen-row pack you can adapt. T is the start of the cutover window. Adjust owners to your organisation; what matters is that every row has one named owner and a date.
| # | Artefact | What it proves | Anchor | Owner | Must exist by |
|---|---|---|---|---|---|
| 1 | Migration test report (functional, integration, performance, security) with sign-off | The workload behaves the same or better in the new environment | TRM 5.7.1, 5.7.6 | QA lead + business owner | T-10 days |
| 2 | Open defect list with each major issue closed or formally accepted | Nobody is carrying a known blocker into production | TRM 5.7.5 | Programme manager | T-3 days |
| 3 | Risk and impact analysis for the cutover change | Security and dependency impacts were considered, not assumed | TRM 7.5.2 | Solution architect | T-10 days |
| 4 | Change advisory board approval record | The change was approved by business and IT, with date and conditions | TRM 7.5.4 | Change manager | T-5 days |
| 5 | Cutover runbook with timed steps, owners and decision points | The weekend follows a script, not memory | TRM 7.5.1 | Cutover lead | T-7 days |
| 6 | Pre-cutover backup confirmation and a restore test result | You can get back to the old state, and the backup actually restores | TRM 7.5.5, 8.4.3 | Infrastructure lead | T-1 day (restore test earlier) |
| 7 | Rollback plan with a rehearsal record and a “point of no return” time | Reverting is a tested option until a known moment | TRM 7.5.5 | Cutover lead | T-5 days |
| 8 | Data reconciliation script and agreed tolerances (row counts, checksums, balances) | What arrived matches what left | TRM 5.7.2 (requirements traced to tests) | Data lead + business owner | Defined T-10, run during cutover |
| 9 | Release record showing who built, approved and deployed (different people) | Segregation of duties and traceability of what moved | TRM 7.6.1, 7.6.2 | Release manager | T-1 day |
| 10 | Cloud access review: privileged accounts listed, MFA on console admins, unused keys removed | The new environment did not inherit loose access from the project | Cloud advisory paras 10–12 | Security lead | T-2 days and T+7 days |
| 11 | Infrastructure-as-code change log with maker-checker approvals; list of any manual changes made during cutover | The live environment matches the reviewed code | Cloud advisory para 26 | Platform lead | T+2 days |
| 12 | Monitoring and security log onboarding check (sample alert received by the SOC) | Cloud logs reach the same people who watched the old system | Cloud advisory paras 27–28 | Security operations | Before go-live sign-off |
| 13 | DR configuration and test plan for the new environment, with RTO/RPO stated | Recovery works in the cloud, including steps that need the provider | TRM 8.2.1, 8.3.4; cloud advisory para 30 | Infrastructure lead | Plan by T-5; first test within your agreed window after go-live |
| 14 | Decommissioning and data-retention record for the old environment | Nothing was switched off before archives were proven restorable | TRM 8.4.2 (backup lifecycle and secure destruction) | Infrastructure lead + records owner | Before old hardware is wiped |
The anchors show your risk team why each row exists; MAS does not prescribe this exact list.
The go/no-go meeting: a decision framework
Run the go/no-go call at a fixed time before the window opens, with the business owner in the room. Use three answers per row, not a vague “green”.
- Go: rows 1 to 9 are complete and signed. Rows 10 to 14 have owners and dates, and none is overdue.
- Go with conditions: one or two rows are incomplete, the gap is understood, and the business owner accepts it in writing with a close-out date. Typical example: the DR test for the new environment is scheduled for two weeks after go-live, with the old environment kept available until it passes.
- No-go: any of these is missing: a rehearsed rollback, a restore-tested backup, a signed test report, CAB approval, or a reconciliation method the business has agreed to. Move the date.
Record the decision and who made it in the change record.
A worked example (illustrative, not a client case)
Picture a Singapore payments company moving its customer-servicing application from a colocation facility to a public cloud region. The team chooses a Saturday night window with a point of no return at 3 a.m. Sunday.
- At the go/no-go call on Friday, rows 1 to 9 are signed. Row 13 is “go with conditions”: the DR failover test in the new environment is booked for the following fortnight, and the colocation servers stay powered on, read-only, until it passes.
- During the window, the reconciliation script compares row counts and account balance totals between old and new databases. One reference table is short by a handful of rows. Because the tolerance was agreed in advance as “zero difference for balances, explained differences only for reference data”, the team can decide in minutes: the missing rows are traced to a filter in the export job, re-loaded, and re-reconciled before the point of no return.
- On Monday, the security team confirms test alerts from the new workload arrive in the SOC. A temporary rule that let the migration team reach the database from their laptops is found in the access review on day seven and removed.
The pack turned three possible incidents into routine decisions with a paper trail.
Mistakes that turn a cutover into an incident
- Rollback written but never rehearsed. A rollback plan that has never been run is a hope, not a control. Rehearse it in a non-production environment and time it.
- No point of no return. Without a fixed time after which you fix forward, teams keep debating rollback at 5 a.m. while customers wait.
- Reconciliation tolerances agreed during the window. Decide in advance what “matches” means for balances, counts and reference data. Arguing about it live is how bad data gets accepted.
- Logs left in the cloud console. MAS’s cloud advisory specifically warns against monitoring cloud workloads in a silo. Prove the SOC sees them before you sign off.
- Manual fixes during cutover never written back into infrastructure-as-code. The next deployment quietly undoes them, or worse, keeps two versions of the truth.
- Old environment wiped too early. Keep it, or a restorable archive, until the new environment’s DR test has passed and retention obligations are recorded.
- Vendor recovery steps assumed. If your cloud provider or managed-service partner has to act during a recovery, TRM 8.3.4 expects those coordinated steps to be tested with them, not described in a slide.
Where a delivery partner fits
If a partner is running the migration, the pack is also your best contract-management tool. Ask for it as a named deliverable, with each row tied to a milestone payment or acceptance step. Our cloud migration service in Singapore treats the pack as part of the scope, and our DevOps team builds the infrastructure-as-code and release records so rows 9 and 11 come from the pipeline rather than from screenshots.
After go-live, the same records feed your hypercare week and the handover to application management. For release strategy on the weekend itself, see blue-green vs canary go-live, and for the first recovery exercise in the new environment, the DR tabletop script for hybrid cloud is a good starting point.
FAQs
Do the MAS TRM Guidelines require a specific cutover document?
No. The TRM Guidelines do not name a cutover document or a migration chapter. They set expectations for testing, change management, release, backup and recovery that a migration has to meet. The evidence pack is a practical way to show you met them for one specific change.
We are not regulated by MAS. Is this overkill?
Trim it, don’t skip it. Rows 1, 4, 6, 7, 8 and 12 (tested workload, approval, restorable backup, rehearsed rollback, reconciliation and working monitoring) protect any business. The regulatory anchors just tell you where the expectations come from.
How early should we start building the pack?
Agree the list and owners when you plan the migration wave, not in the final week. Most rows are by-products of work you already do; they only hurt when reconstructed afterwards.
Who should sign the go/no-go decision?
The business owner of the application, together with the IT lead accountable for the change. For regulated firms, follow your own change-approval policy; TRM 7.5.4 expects a change advisory board including business and IT management to approve changes.
What to do next
Copy the fourteen rows into your migration plan, put a name and a date next to each, and review it at every steering meeting until cutover. If you want a second pair of eyes on a live migration plan, or a partner who delivers the pack as part of the work, start with our cloud migration Singapore page or contact WC1.