Cloud Migration Checklist

Why migrations go wrong

Most cloud migrations don't fail because of technology. They fail because nobody made a list of everything the old system was quietly doing — the scheduled report, the integration to the accounting file, the one spreadsheet that only works on the server. The migration itself takes a weekend; discovering what you broke takes a month. This checklist front-loads that discovery so the cutover is boring, which is exactly what you want.

It's written for Australian SMEs moving line-of-business systems — file servers, accounting, job management, email — to cloud platforms. Work through it in order: scope, prepare, migrate, verify, decommission.

Before you commit: scoping

• Inventory every system and its dependencies. List each application, where its data lives, what connects to it, and who uses it. The integrations you forget are the ones that break.
• Identify your data sensitivity. If you hold personal information, check your obligations under the Privacy Act and the Notifiable Data Breaches scheme — the OAIC's current guidance is the authority here.
• Check data residency. Confirm where the provider stores Australian customer data. Some contracts and industries require onshore storage; ask before you sign, not after.
• Read the exit clause. Know how you'd get your data out, in what format, and at what cost, before you put it in.
• Confirm internet capacity. Cloud systems live and die on your connection. Test bandwidth and have a fallback (such as mobile failover) for the office.

Preparation

• Clean before you move. Archive or delete stale data now — migrating seven years of junk costs time and money and makes the new system worse from day one.
• Map old structure to new. Decide folder structures, naming conventions and permissions in the new platform deliberately, rather than replicating the mess.
• Set up identity and access first. Create user accounts, groups and permission tiers before data lands. Enable multi-factor authentication for everyone — it's a core control in the ACSC's Essential Eight for good reason.
• Take a full, verified backup. A backup you haven't test-restored is a hope, not a backup. Keep it independent of both old and new systems until well after cutover.
• Schedule the cutover window. Pick a low-activity period, tell every user what will be unavailable and when, and name one person as the decision-maker if something goes sideways.

Migration and cutover

• Run a pilot with one team or dataset. Find the surprises with five users, not fifty.
• Migrate in stages, verify each stage. Check record counts, file counts, and spot-check documents open correctly before moving to the next batch.
• Reconnect integrations one at a time. Accounting feeds, e-signature tools, payroll connections — test each with a real transaction.
• Freeze the old system at cutover. Make it read-only so nobody keeps working in it. Dual-entry chaos is the most common post-migration mess.

Verification and sign-off

• Have each team lead confirm their critical workflows. Not "can you log in" — can they raise an invoice, find last year's contract, run the report they use every Monday.
• Test a restore from the new platform's backup. Confirm what the provider backs up, how long they retain it, and what's your responsibility — it's usually more than owners assume.
• Update your documented procedures. Every process that referenced the old system needs its steps refreshed. If those procedures live in people's heads, this is the moment to write them down — see how to systemise your business.
• Review access after the dust settles. Remove migration-only admin accounts and check that permissions match what you designed.

Decommissioning the old system

• Keep the old system accessible (read-only) for an agreed period, then retire it formally — don't let it linger as a security liability nobody patches.
• Confirm record-keeping obligations before deleting anything. The ATO and other regulators set minimum retention periods for business records; check the current requirements for your records before destruction.
• Securely wipe or destroy old hardware and get certificates of destruction where third parties do it.

A migration done this way is a chance to rebuild your operations layer properly, not just relocate it — our operations page covers what a well-run back office looks like after the move.