Most cloud migrations do not fail because the cloud is complicated. They fail because of things nobody wrote down: a hard-coded IP address inside a billing application, a shared drive two departments both depend on, a DNS record last edited in 2021. Work through this list before you book the cutover window, not during it.
The broader planning context is covered in cloud services, but this is the pre-migration checklist itself.
Build an inventory you can reconcile
Start with a spreadsheet, not a questionnaire. One row per system, with columns for owner, where it runs, number of users, and what breaks if it is unavailable for four hours. A spreadsheet is auditable. A survey response from a department head who stopped using the software eighteen months ago is not.
Reconcile it against reality twice. First against what the accounts team says they use. Then against what the servers are actually running. The gap between those two lists is the most valuable output of the whole exercise, because that is where your risk lives.
Include the unglamorous items: the WhatsApp Business account tied to a personal phone, the Tally data folder on an unassigned desktop, the Wi-Fi router configuration, the CCTV recorder, the biometric attendance device. Migration projects reliably discover these in week three.
Map dependencies before you touch anything
For each system, write down what it talks to. Does the billing software call a remote Tally server? Does the website read from the CRM database directly? Does an email signature point at a local image path?
A dependency that only surfaces at cutover is a dependency that stops the migration. Spend a full day on this for a ten-person office. It is the cheapest day in the project.
Test in a copy, not in production
Stand up a non-production version of each workload and put real work through it. Not a sample dataset. Actual last quarter’s data, because empty databases hide triggers, scheduled jobs and validation rules that only fire once real values are present.
Then do the bandwidth arithmetic honestly. A 2 TB transfer over a 100 Mbps line is a theoretical 46 hours before overhead. Real throughput lands closer to 60 to 70 percent of line rate, so plan three to five days for that volume. Uploading 2 TB will also saturate your office internet and slow every other system to a crawl while it runs, which is why migration windows are scheduled at night.
Why DNS TTL matters more than most people think
Time to live controls how long resolvers cache a record. Leave it at 24 hours and a cutover becomes a 24-hour problem: the old record is still cached on resolvers you do not control, and inbound mail bounces for a day after you believe you have switched.
Drop the TTL to 300 seconds at least 48 hours before cutover. Wait one full old TTL for the change to propagate everywhere. Make the switch. Raise it back to 3600 once things are stable.
This one habit removes the most common cause of a “the migration failed” phone call. Mail routing records matter most here, because a stale MX record means mail landing on the old server while your team has already moved across.
What commonly breaks at cutover
- Licences tied to the machine. Desktop Office and some accounting packages deactivate when the hardware fingerprint changes. Re-activate before cutover, not after.
- Hard-coded IP addresses. Printers, CCTV recorders and internal tools reached by fixed address stop resolving. Move them to hostnames or DHCP reservations.
- Backup jobs pointing at a NAS nobody migrated. New environment, no backups running, nobody notices for three weeks. See backup and disaster recovery for how to avoid that.
- Permissions flattened during transfer. A file copy without security descriptors silently drops ACLs. The migration “succeeds” and everyone now has access to the salary folder.
- Date and time zone conversion. Export to spreadsheet, re-import into an accounting system, and dates shift. Reconcile GST report totals before declaring victory.
- Nobody cancelled the old provider. The old server stays live, costs continue, and someone keeps using it.
When to skip the formal exercise
If your entire estate is one file server and one office router, this checklist is overkill. Move the files to managed storage, leave the router alone, and spend the effort on email instead. A checklist earns its keep when database servers, custom applications or business-critical integrations are involved. If that is not your situation, keep it short. Most SMBs needing a structured run should start with AWS cloud migration or Azure cloud setup planning rather than a full lift-and-shift.
FAQ
How long does a small business migration actually take? For a ten-person office with one file server and one accounting system, a weekend. Add a database, custom software or multiple office locations and you are looking at two to four weeks of preparation before anything is moved.
Do we have to move Tally at the same time? Not immediately. Tally can stay on a local machine while everything else moves. But if its licence is tied to that machine, migrate the licence before the hardware, not after.
Should email move first? Usually yes. It is the lowest-risk workload and it takes the old server out of daily use, which makes the rest of the migration less stressful.
What gets missed most often? Network bandwidth, and who owns it. If your ISP needs a week to provide a second line or a static IP, find that out during planning.
Can we do this over a long weekend? Only if dependency mapping is finished. Otherwise you will spend Sunday night rolling back.
Get migration help
24Bit System runs migration assessment, planning and cutover for Indian SMBs on AWS, Azure and Google Cloud. Call +91 7840002466.
