Moving an application or website to the cloud is less about the destination and more about the move itself. Done carefully, it gives you better reliability, backups you can trust and room to grow. Rushed, it trades an old server's problems for a larger and more confusing bill. This checklist is the sequence we typically follow for small and mid-sized businesses.
1. Audit what you actually run
You cannot move what you have not listed. Before choosing any service, document:
- Every application, website, database, scheduled job and file store, and where each one currently lives.
- How they connect: which app talks to which database, plus third-party APIs, payment gateways, and email and SMS providers.
- Domains, DNS records, SSL certificates, and who controls the domain registrar account.
- Current traffic patterns, busy periods and storage size.
- Credentials and secrets, and where they are stored today — often the most uncomfortable part of the audit.
The audit regularly turns up forgotten scheduled jobs, hard-coded IP addresses and servers nobody remembers setting up. Finding them now prevents surprises on cutover day.
2. Choose managed services over do-it-yourself servers
The most common mistake is to recreate the old server exactly on a cloud virtual machine and call it a migration. You get a cloud bill without most of the cloud's benefits. For small teams, managed services usually make more sense:
- Managed databases, such as PostgreSQL or MySQL on Amazon RDS, handle patching and automated backups and offer failover options.
- Object storage, such as Amazon S3, for uploads, media and backups instead of a server's local disk.
- Containers built with Docker keep the app consistent between environments; run them on a managed container service rather than looking after the hosts yourself.
- A CDN in front of static assets and pages to improve speed for visitors far from your servers.
Kubernetes is powerful, but for most small businesses it adds operational overhead they do not need yet. Start simpler and grow into it when the workload justifies it. Our AWS cloud page covers the services we use most often.
3. Backups and recovery you have actually tested
Backups only count if you have restored from them. Set up:
- Automated database backups, with point-in-time recovery where available.
- Versioning or scheduled copies for file storage.
- Copies kept in a separate account or region from production.
- A written restore procedure, and a test restore before go-live and at regular intervals afterwards.
Agree two answers with the business: how much data you can afford to lose, and how long you can afford to be offline. Those two answers decide how elaborate your backup and failover setup needs to be.
4. CI/CD and repeatable environments
Migration is the right moment to stop deploying by copying files onto a server. A basic CI/CD pipeline builds, tests and deploys every change the same way, with a clear history and a simple rollback. Pair it with a staging environment that mirrors production, so changes are checked before customers see them.
Where practical, define infrastructure as code, so environments can be recreated reliably rather than rebuilt from memory. Our cloud and DevOps engagements usually start here, because it makes every later step safer.
5. Security, monitoring and cost control
Security basics
- Protect the root account with multi-factor authentication, stop using it day to day, and give each person their own login with only the access they need.
- Keep databases in private networks, not open to the internet.
- Store secrets in a secrets manager or encrypted parameters, never in code repositories.
- Enforce HTTPS everywhere and keep operating systems, runtimes and dependencies patched.
- Turn on audit logging so you can see who changed what, and when.
Monitoring and cost
Before go-live, set up uptime checks, error tracking and alerts on CPU, memory, disk and database health, routed to people who will act on them. Centralised logs make diagnosing problems far quicker than logging into individual servers.
For cost, set budgets and billing alerts on day one, tag resources by project and environment, and review usage monthly. Common sources of waste are oversized instances, staging environments left running around the clock, unattached storage volumes and old snapshots. Right-size after a few weeks of real usage rather than guessing upfront.
6. A staged cutover plan
- Build and test in the cloud while the old environment keeps serving customers.
- Lower DNS TTLs a few days ahead so the switch takes effect quickly.
- Rehearse the data migration on a copy and time it, so you know how long the final sync will take.
- Schedule a low-traffic window, announce any maintenance and freeze changes.
- Run the final data sync and switch DNS, then watch monitoring closely.
- Keep the old environment available for a short rollback period before decommissioning it.
Planning your move
A good migration is mostly preparation: a clear inventory, sensible managed services, tested backups and a rehearsed cutover. If the system you are moving is a set of spreadsheets that has outgrown itself, our guide to the signs your business needs an ERP or CRM may be the better starting point. For a migration plan built around your applications, contact us and our cloud team will review what you run today.
