In this guide 6 sections
Start with a written inventory of every server, application, database, file share and login you rely on. Move the low-risk pieces first and leave old or fragile ones alone. Set up backups and access before cutover, and rehearse the switch once. Moving everything in one weekend is the usual mistake.
Write down what you actually run
Most small companies cannot list their own systems from memory. Walk the office. Open the cupboard holding the NAS box, the router and the spare desktop, then log in to the domain registrar and the mail admin page.
For each item, note the owner, where the data lives, what it connects to and when it last received an update, using nothing fancier than a shared spreadsheet. Forgotten links break on cutover day. Everyone remembers the database; nobody remembers the cron entry.
A label printer script that reads from the accounts database is a classic, and so is a nightly mysqldump written by a contractor who left. Find them now. Later is too late.
- Servers, hypervisor guests and desktop PCs quietly acting as servers
- Databases and every application that reads them
- File shares, mailboxes and scanned documents
- Scheduled jobs, SFTP drops and printer or scale links
- Domain, DNS records and certificate renewals
Decide what moves first and what stays
Begin with something that costs little if it goes wrong. A staging copy of the company website, an internal wiki or a reporting database makes a good first move, because your team learns the console while stakes stay low.
Leave the awkward pieces for later. A twenty-year-old desktop program tied to a licence dongle and a serial-port scale may never belong in the cloud. Keeping it on site is a decision, not a failure.
Ask honestly whether moving helps at all. If the system runs, patches are applied and someone watches the RAID array for failed disks, a migration adds risk for small gain. Move for a reason. Failing hardware, an unsupported operating system or a stalled roadmap all count.
- Low risk and well understood: move first
- Customer-facing and revenue-critical: move after a rehearsal
- Old, dongle-bound or hardware-tied: review before deciding
Fix backups and access before the move
A new platform without a tested restore is only a new place to lose data. Decide what gets backed up, how often, where the copies live and who may delete them. Then restore one backup into a clean environment. Check the records by eye.
Sort out access at the same time. Give every person a personal login, switch on a second sign-in step for administrators, and write down who holds the root account and the billing contact for the provider. Sticky-note passwords do not survive a move.
Keep the old system’s last backup read-only until the new one has completed a full month-end close without a surprise. It costs almost nothing. Delete it afterwards, not before.
Plan the cutover like a small event
Pick a quiet window and tell staff, customers and suppliers early. Freeze changes on the old system, copy the data across with rsync or a database dump, point the application at the new database and test the main tasks. Billing. Login. Reports. Email.
Lower the DNS time-to-live a few days ahead so the address change spreads quickly, and copy the MX, SPF and DKIM records exactly as they stand. Mail landing in spam after a move is a common surprise.
Write the rollback rule before you start. If invoices cannot be raised by an agreed hour, the team returns to the old system and tries again next weekend. Decide this while calm, not at midnight.
- Change freeze and final data copy
- Smoke test of billing, login, reports and email
- A named person who can call a rollback
- Staff briefed on what will look different
Watch the running costs after you arrive
Cloud bills grow quietly. Test servers left switched on, snapshots nobody deletes, egress from customer file downloads and oversized databases add up month after month. Tag every resource with an owner and a purpose.
Check the first two invoices line by line against your inventory. Anything unexplained is waste, or something you forgot to list. Both are worth knowing.
Do one thing today. Open a blank sheet, list every system you run, and put a name beside each one before you contact a single provider.
Cloud migration inventory sheet
A one-page sheet with one row per system. Columns: system name, owner, data location, connections, backup method, risk if moved, planned order and rollback note. A second block lists domains, certificates and logins with renewal dates.
Open a blank worksheet to printQuestions owners ask
Should a small business move everything to the cloud?
Not necessarily. Systems that run well and are tied to local hardware can stay. Move what is failing, ageing or hard to back up, and leave the rest until there is a reason.
How long does a cloud migration take?
That depends on how many systems you have and how well they are documented. A single website can move in days. Connected applications with databases need weeks of preparation and one rehearsal before the real cutover.
Who should own the migration inside the company?
One named person with authority to decide, usually an operations lead or the owner. Engineers do the technical work, but someone inside the company must approve the cutover and the rollback.
What goes wrong most often?
Forgotten dependencies. A script, a printer link or a scheduled export stops working because nobody listed it. An inventory and a rehearsal catch nearly all of these before real users do.