AWS migration checklist for mid-market companies

Why does a mid-market AWS migration need a checklist?

Because the risk in a mid-market move sits in the details nobody wrote down: a nightly script on an old server, a vendor that whitelists one IP address, a finance report that reads straight from the production database. A checklist forces those into the open before cutover day instead of after it.

Large enterprises usually have a cloud team, an architecture board and a change calendar. Small startups have three servers and one engineer who knows all of them. Mid-market companies sit in between. They run real revenue on systems that grew over ten or fifteen years, and the knowledge of how those systems connect lives in a few people’s heads. That is exactly the setup where a move goes sideways.

The list below is grouped into six phases. You can skip items that clearly do not apply to you, but we suggest you skip them on purpose, with a note saying why, rather than by forgetting. The same habit carries through the whole project.

1. What should you inventory before moving to AWS?

Every workload, the data it holds, who owns it, what it talks to and when its current hosting contract ends. If you cannot name an owner for a server, write that down as your first finding.

• Servers and services. Physical boxes, virtual machines, managed hosting accounts, the forgotten VPS someone pays for on a personal card.
• Scheduled jobs. Cron entries and Windows scheduled tasks are the items most often missed. List each one with what it does.
• Data stores and sizes. Databases, file shares, object storage and backups, with rough sizes and how fast each one grows.
• Connections. Which app calls which, which outside vendors connect in, and any partner that allows traffic from a fixed IP only.
• Contract dates. Colocation leases, hosting renewals and software license terms. Your timeline should count back from the earliest one.
• A cost baseline. What you spend today on hardware, hosting, power, support contracts and staff time, so the business case compares like with like.

Tools can help here. AWS has discovery tooling that collects server specs and network connections, and many teams already run a monitoring product that knows what talks to what. Still, plan on interviews. The person who set up the payroll export in 2017 knows something no scanner will find.

2. How do you decide what happens to each application?

Give every app one of AWS’s seven migration strategies, usually called the 7 Rs, and write down the reason. Most mid-market portfolios end up mostly rehosted or replatformed, with a handful retired and one or two rebuilt later.

Two questions decide most of these calls. How much downtime can this app take during the switch, and how much would it cost to change its code? An internal wiki can be offline for a Saturday afternoon. An order system that feeds the warehouse probably cannot, which pushes it toward a replication-based move with a short final cutover.

Watch licensing closely at this step. Some database and operating system licenses are tied to physical cores or specific hosts, and moving them to shared cloud hardware can change what you owe. Read each vendor’s terms before you pick a strategy.

Repurchase deserves a serious look for back-office systems. If an on-premise CRM or ticketing tool is due for an upgrade anyway, moving it to Zoho CRM or another SaaS product can remove a server from the plan entirely. We say that as a team that builds on both AWS and Zoho, so we have no reason to push either one.

3. What goes into an AWS landing zone?

A landing zone is the account structure, sign-in, network, logging and guardrails you set up before the first workload arrives. Building it first is cheaper than retrofitting security onto an account that already runs production.

• Separate accounts for production, testing and shared services, grouped under AWS Organizations, so a mistake in one cannot touch the others.
• Root user locked down with MFA and stored credentials nobody uses day to day.
• Staff log in via IAM Identity Center, ideally linked to the directory you already use, with roles that grant only what each job needs. Our AWS IAM page goes deeper.
• A network plan with IP ranges that will not clash with your offices or VPN, private subnets for databases and a clear path for outbound traffic.
• Logging and alarms: CloudTrail on in every account, and CloudWatch alarms for the few signals that matter on day one.
• Tags and budgets agreed upfront (team, environment, app), with budget alerts so a runaway resource shows up in days rather than on the invoice.
• Backups set by policy, with at least one restore actually tested.

None of this is exotic. It is the part teams skip when they are in a hurry, and it is the part that decides whether your AWS environment is still tidy two years later.

4. Why start with a pilot application?

A pilot proves your runbook, your rollback and your team’s habits on something low-stakes. Pick an app that matters a little, so people actually test it, but whose outage would not stop sales or payroll.

Good pilots are internal reporting tools, a staging environment or a departmental app with a patient owner. Move it end to end exactly as you plan to move the important systems: same replication method, same DNS change, same smoke tests. Then roll it back on purpose and move it again. Teams that skip the deliberate rollback tend to discover on cutover night that the old server cannot be brought back cleanly.

Write down everything the pilot taught you. Expect a few surprises: a firewall rule nobody knew about, a hard-coded hostname, a certificate that lived only on the old box. Each one becomes a line in the runbook for every later wave.

5. How do you plan the cutover waves?

Group apps that depend on each other into the same wave, schedule each wave in a window the business agrees to, and decide in advance what would make you roll back. The decision rule matters more than the date.

• Dependency groups. An app and the database it reads from move together, or the link between them is tested across the network first.
• Continuous data sync until the switch, using AWS Application Migration Service for servers and AWS Database Migration Service for databases, so the final copy is small.
• Lower DNS time-to-live a few days before, so the switch spreads quickly and a rollback does too.
• A change freeze on the systems in the wave, announced to the teams who use them.
• Smoke tests written in advance by the people who use the app, not only by engineers.
• Go and no-go criteria. For example: if order sync fails for more than an agreed number of minutes, switch back and regroup.
• A named person on each side who can make the rollback call without waiting for a meeting.

Tell vendors and partners early. Payment gateways, shipping carriers and banks that allow traffic from known IP addresses need the new addresses before the switch, and some of them take a while to update.

6. What should happen after you move to AWS?

Watch the new environment closely for a few weeks, then tune it with real usage data: resize what is oversized, commit to pricing plans only for steady load, switch off the old hardware and hand over documentation.

Right after a move, servers are often sized to match the old hardware, which was itself bought for peak load years ago. Once you have several weeks of CloudWatch metrics, resizing is usually the quickest saving. Commitment pricing such as Savings Plans comes after that, and only for the part of your usage that is truly steady. Committing on day one locks in guesses.

This is also the time to modernize carefully. A file share might move to Amazon S3, a public website might go behind CloudFront, a busy app might move into containers. Each change is easier on a stable platform than in the middle of a migration.

Finally, close the loop with the business systems. Many of the companies we work with run sales and accounting in Zoho and their product or portal on AWS. Linking the two properly, so orders, customers and invoices stop being typed twice, is often where the move starts paying back. Our integrations work covers that side.