Cloud Migration Checklist
Move to the cloud without breaking the business
Use your browser's find-in-page to jump between sections. Reading progress is shown at the top of the page.
Before you move
List every system, who uses it, what data it holds, and what breaks if it is offline for a day.
A cloud migration fails in the planning stage far more often than in the technical stage. Start with a complete inventory — not just the servers you remember, but the full picture. Walk through each department and ask what they actually use: the accounting package, the shared drives, the old desktop app that one person still runs for reports, the printer software nobody admits to needing. Shadow IT is real, and the migration plan that misses it is the one that breaks on go-live day.
For each system, record four things:
- Who uses it, and when. Daily core systems need different handling than the archive that gets opened twice a year. Note peak hours — migrating the invoicing system at month-end is asking for trouble.
- What data it holds, and where that data lives. Databases, file shares, local PST files, USB backups in a drawer. Data you do not know about cannot be migrated or secured.
- Dependencies. What talks to what? The reporting tool that reads from the accounts database, the barcode printer driver, the integration with the bank. Draw the map before you touch anything.
- What breaks if it is offline for a day. This is your risk register. Anything marked “the business stops” gets migrated with extra care, a tested rollback plan and a maintenance window everyone agrees to.
Also check the boring prerequisites: internet bandwidth at each office (a cloud system on a slow connection feels broken even when it is not), licensing (are your current licences even allowed in the cloud?), and compliance (where is customer data allowed to live, legally, for your business?).
The checklist
Inventory and dependencies. Data cleanup and backup. Security and access control. Pilot with one team. Migrate in stages. Test restores. Train staff. Switch over with a rollback plan.
Here is the sequence in practical order:
- Inventory and dependency map. As above — every system, user, dataset and dependency, written down.
- Data cleanup. Migrate less, not more. Archive what is dead, deduplicate what is doubled, and fix the folder structure that grew organically for a decade. Moving ten years of clutter to the cloud just gives you expensive clutter.
- Backup before anything moves. A full, tested backup of everything. “Tested” means you actually restored something from it — a backup you have never restored is a hope, not a backup.
- Security and access control. Define who can access what before migration, not after. Use roles, not individual permissions per person — when someone changes job, you change one role assignment. Enable multi-factor authentication from day one; retrofitting it later is painful.
- Choose the migration order. Move the least critical system first. Learn on something that will not stop the business if it stumbles.
- Pilot with one team. Migrate one department or branch, run them on the cloud version for one to two weeks, and fix every issue they find. They are your canaries and your future internal champions.
- Migrate in stages. System by system, with a stable period between each. Big-bang migrations — everything over one weekend — fail spectacularly when they fail.
- Test restores in the new environment. Backups in the cloud are a different mechanism than backups on your server. Prove you can restore before you need to.
- Train staff before switchover. Not a PDF manual — a short hands-on session on the actual new system, with their actual data. People resist what they have not touched.
- Switch over with a rollback plan. For each system, write down the exact steps to go back if something goes wrong, who decides, and the time limit. A rollback plan you never use is still worth writing.
Common mistakes
Moving everything at once, forgetting backups, and skipping training. All three are avoidable.
Beyond the big three, here are the mistakes we see most often:
Underestimating the internet connection. Cloud apps are only as good as your link. Test real-world speed at each location during working hours, and have a fallback (a second ISP or 4G/5G backup) for the office that cannot afford downtime.
Migrating the mess. Old permissions, dead user accounts, duplicate files — if you move it all, you pay to store it and you confuse everyone longer. Clean first.
No ownership after migration. Someone needs to own the cloud environment: user management, cost monitoring, updates, access reviews. “The IT guy will handle it” is not a plan if the IT guy was the server under the desk.
Ignoring costs. Cloud pricing is usage-based, which means it can grow quietly. Set up billing alerts from the start, review monthly, and shut down what you are not using. A forgotten test server running for a year is a classic.
Skipping the rollback test. Teams write rollback plans and never rehearse them. Then, at 2am during a failed cutover, nobody is sure the plan works. Walk through it once, calmly, in daylight.
How long does it take?
It depends on what you are moving, but here is a realistic shape: one to two weeks for inventory and planning, one week per system for cleanup and pilot, and staged migration over several weeks after that. A small business with email, files and one line-of-business app can be done in four to six weeks. A multi-branch operation with custom software and integrations is a two- to four-month programme. Anyone promising “a weekend” for the second case is selling, not planning.
Questions we hear often
Do we need to change our software to move to the cloud? Not always. Some desktop applications run fine on cloud-hosted desktops or virtual machines. But web-based software — like HdeBooks, which is cloud-based by design — gives you the full benefit: access from anywhere, no servers to maintain, automatic backups.
What about our data — is the cloud safe? For most small and mid-size businesses, a reputable cloud provider’s security is far better than a server in the office. The risks that remain are yours to manage: strong passwords, multi-factor authentication, and sensible access roles. Those three cover the vast majority of real incidents.
Can we go back if we do not like it? That is exactly what the rollback plan is for — per system, decided in advance. In practice, almost nobody goes back once staff are trained and the first month’s stability proves itself. The fear is bigger than the reality.
Should we migrate everything? No. Keep what works where it works. The goal is not “100% cloud” — it is reliable, secure, maintainable systems. Sometimes that means one legacy app stays on a local machine while everything else moves.
How we help
We plan and support cloud migrations and cloud-based software — see our Cloud Solutions service. We start with the inventory and risk assessment, pilot with one team, migrate in stages, and stay through training and the first month of live running. If your core system is accounts, POS or stock, HdeBooks ($100.00, now $50.00) is already cloud-based — no migration project needed, just setup and training. Contact us to talk through your systems.
Work with Huzi Developers
Huzi Developers has built software since 2003 — custom software, web apps, mobile apps, HdeBooks and HDe School. Contact us or visit the Shop to get started.