Moving to the Cloud: A Migration Plan for a Small Business

List every application, server, database, file share and integration, including the ones nobody wants to admit exist. For each, record:

• What it does and who uses it.
• Who owns it, and who is the technical contact.
• Its dependencies: databases, licenses, hardware, other systems and scheduled jobs.
• Its data: how much, how sensitive and how often it changes.
• Its uptime needs and what happens to the business if it's down for a day.

Talk to the people who use each system, not just the IT staff. A spreadsheet in a finance department that feeds an invoicing process is a system, and it will break if it's forgotten. This inventory becomes your project scope and your safety net.

Sort every item into one of these choices. Most small businesses end up using several:

1. Retire: nobody uses it. The cheapest migration is deleting it.
2. Replace: swap it for a hosted service, such as moving an in-house email or file server to a software subscription.
3. Rehost: move the server largely as-is to a virtual machine in the cloud. It's the fastest, and it doesn't reduce operating work much.
4. Replatform: move with modest changes, such as switching to a managed database.
5. Keep: leave it on premises if it depends on local hardware or a migration isn't worth the risk.

Prefer replacing and retiring first, because they remove work rather than moving it. Rehosting everything gives you the same maintenance burden at a new address, with a monthly bill.

Set up the foundation first, because retrofitting security later is painful:

1. Create separate accounts or projects for production and non-production.
2. Connect the cloud to your identity provider, and enforce multi-factor authentication for every human and admin user.
3. Give people roles with the least access they need, and avoid shared admin accounts.
4. Design the network: private subnets for data, a controlled path in from the internet and no public database endpoints.
5. Turn on audit logging and send it to a separate, protected location.
6. Set budgets and alerts before workloads arrive.
7. Define backups and test a restore.

Write your security expectations in your information security policy so the cloud follows the same rules. On patching, CISA's federal directive BOD 19-02 sets 15 days for critical vulnerabilities on internet-accessible systems¹, a reasonable benchmark for your own target.

Choose a first workload that's useful but forgiving, such as an internal tool or a reporting database, and take it all the way through. The pilot proves your landing zone, your pipeline and your team's skills, and it produces real cost numbers.

For each production cutover, prepare a runbook with these parts:

• A rehearsal in a test environment, timed, with the results recorded.
• A data sync plan that keeps the source and target aligned until the switch.
• A cutover window chosen for low business impact, with clear go and no-go criteria.
• A rollback plan that keeps the old system intact and untouched for a defined period.
• A communication plan for staff and customers.

Say you migrate a customer database on a Saturday night. Rehearse the sync twice, keep the old database read-only afterward for two weeks and have someone verify key reports on Monday.

Migration isn't done at cutover. Plan these steps:

• Monitor and set service targets. Decide what good performance looks like using a reliability target, and alert when it slips.
• Prepare for incidents. Update your incident response plan and ransomware playbook for the new environment.
• Right-size and review cost monthly. The first bills are often higher than the estimate because both environments run in parallel.
• Train staff on the new tools and the on-call path.
• Decommission the old environment only after the agreed grace period, wiping disks and closing contracts and licenses.

Compare provider choices in the cloud provider comparison before you commit, and revisit the decision in a year with real data.