A small business cloud migration goes well when you take inventory of what you have, decide what happens to each system, build a secure place for it to land, move in stages, and keep the old system running until the new one is proven. The checklist below follows four phases, assess, plan, deploy and optimize, which match the phases Google Cloud describes in its own migration guidance.
Print it, assign an owner to each line, and don’t schedule a cutover until every box in the first two phases is checked.
Phase 1: Assess what you have
Most migration problems start here, with something nobody knew was connected to something else.
- List every application, server, file share and database you’re considering moving.
- Name a business owner for each one: the person who’ll say whether it works after the move.
- Map dependencies. Which systems talk to each other, and which ones break if one moves first?
- Record what each system costs today, including hardware, licenses, support and the space it sits in.
- Note what kind of data each system holds and any contract, client or regulatory rules about where it can live and who can access it.
- Write down the business reason for moving. “The server is five years old and our second office can’t reach it” is a reason. “Everyone’s in the cloud” isn’t.
Phase 2: Plan the move
- Choose the platform. AWS, Microsoft Azure and Google Cloud all work well for small businesses. The right choice depends on what you already use, the skills your team or provider has, and the specific services your systems need.
- Decide what happens to each workload. AWS groups the options into seven migration strategies: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. For many small businesses, the honest answer for a few systems is retire (turn it off) or repurchase (replace it with a cloud app).
- Don’t modernize everything at once. AWS’s guidance for large migrations recommends rehosting, relocating or replatforming first and modernizing after the migration is complete, because refactoring during a move is the most complex path.
- Understand shared responsibility. The cloud provider secures the underlying infrastructure; you’re still responsible for things like your data, user access and configuration. AWS and Microsoft both publish their versions of this model. Read the one for your platform.
- Pick a data transfer method. Microsoft’s migration planning guidance walks through the options, from a private connection or VPN to shipping a physical device for very large data sets. File size and internet speed decide how long this takes.
- Sequence the work. Move a low-risk system first to prove the process, then the rest in batches.
- Write a rollback plan. For each batch, decide in advance what “failed” looks like and how you’ll go back.
- Plan communication. Tell staff what changes, when, and who to call on the first morning.
Phase 3: Deploy
- Set up the cloud environment before moving anything: accounts, structure, naming and billing alerts.
- Turn on multifactor authentication for every administrator account and give people only the access they need.
- Configure backups and confirm you can restore from them before go-live, not after.
- Turn on logging so you can see who changed what.
- Run a test migration with a copy of the data and have the business owner check it.
- Schedule the cutover for a low-impact window and freeze changes to the old system.
- Validate after cutover: business owners sign off that their system works the way it did, or better.
- Keep the old system available, read-only, until sign-off is complete.
Phase 4: Optimize
- Review the first full month’s bill against your Phase 1 cost baseline.
- Right-size anything that’s bigger than it needs to be and shut down test resources.
- Decommission the old hardware and cancel the old contracts, so you stop paying twice.
- Update your documentation: what lives where, who owns it, and how to recover it.
- Schedule a review against the provider’s best-practice framework. On AWS, that’s an AWS Well-Architected Review.
Five questions to answer before you set a date
- Can every system owner say what “working” looks like after the move?
- Do we know every dependency between the systems we’re moving?
- Have we restored from a cloud backup at least once?
- Do we know what we’ll do if cutover fails?
- Who manages the environment day to day after go-live?
That last question matters more than most people expect. A migration is a project. Running the environment afterward is ongoing work, and it needs a clear owner.
How we help
Balancelogic® Cloud Migration Services start with the plan: assessment, platform selection and a phased move with as little downtime as possible. Balancelogic is an AWS Select Tier Partner and also supports Microsoft Azure and Google Cloud. After the move, our Cloud Managed Services can keep the environment running and accountable. You can see all of our cloud services in one place.
Balancelogic partners with our sister company ITAssurance℠ when ongoing managed IT, cybersecurity, and operational support are needed.
Planning a move in the next year? Book a free IT Strategy Session and bring your inventory.
Frequently asked questions
What should a cloud migration checklist include?
Four phases: assess what you have and who owns it, plan the platform, strategy and sequence for each system, deploy with security and backups in place, and optimize costs and documentation after the move.
Which cloud platform is best for a small business?
AWS, Microsoft Azure and Google Cloud can all work well. The best choice depends on the systems you already use, the skills available to you and the specific services your applications need.
Is the cloud provider responsible for securing my data?
Partly. Under the shared responsibility model, the provider secures the underlying infrastructure, and you remain responsible for things like your data, user access and configuration. The exact split depends on the service you use.
Should we modernize our applications during the migration?
Usually not all at once. AWS’s guidance for large migrations recommends rehosting, relocating or replatforming first and modernizing after the migration is complete, because refactoring during a move adds complexity and risk.
This article is general information, not legal or professional advice for your specific situation.
