Home · About · Services · Industries · Projects · Products · Process · Blog · FAQ · Contact
Cloud migration checklist: moving off shared hosting or on-prem A step-by-step checklist for moving a website, app or office server to the cloud: inventory, target design, data sync, DNS cutover, rollback and the first two…
The move usually starts with a trigger. The shared host throttles the site whenever traffic spikes. The server in the office cupboard is out of warranty and the person who set it up has left. Or a client questionnaire asks where backups are kept and nobody can answer. The migration itself is rarely hard. What goes wrong is the thing nobody wrote down: a cron job, a mailbox, a hard-coded IP address.
The short answer: a cloud migration checklist has five stages. Inventory everything the old system does, design the target, rehearse the move on a copy, cut over with low DNS TTLs and a final data sync, then keep the old system running untouched until the new one has proved itself. Most failed migrations skip the inventory or the rollback plan.
1. Inventory what the old system actually does Old servers collect responsibilities quietly. Before choosing a provider, list every job the old machine performs. We go through the control panel, the crontab, the web server configuration and the DNS zone, and ask the people who use the system what they would notice if it stopped.
Applications and their runtime versions: PHP, Node, Python, Java, and the database engine and version. Databases, their sizes and how fast they grow. Uploaded files and any other data stored on disk outside the database. Scheduled tasks: crontab entries, control panel cron jobs, Windows Task Scheduler. Email: mailboxes, forwarders and outgoing mail the application sends. Shared hosting often bundles email, and moving the website does not move the mail. DNS: every record in the zone, including MX, SPF, DKIM, DMARC and verification TXT records. TLS certificates and who renews them. Rewrite and redirect rules, for example in .htaccess files. Integrations: payment callbacks, SMS gateways, third-party APIs that allow-list your current IP address. Users and access: who has logins today, and which of those people still work with you. Two items cause most surprises. First, email: if the domain's MX records point at the shared host and you cancel the hosting, mail stops. Decide early whether mail moves to Microsoft 365, Google Workspace or another provider, and migrate it as a separate project. Second, IP allow-lists: a bank, payment gateway or partner API that only accepts requests from your old IP will reject the new server until they update their list, which can take days.
2. Design the target before you build it Most small and mid-sized systems do not need a complex cloud architecture. A single well-sized virtual machine with Docker or a managed platform, plus off-server backups, is often a large step up from shared hosting. The decisions that matter are these.
Provider and region: pick a region close to your users and check any data residency expectations from clients or regulators. Compute: a VM such as AWS EC2, Lightsail or an Azure VM for lift-and-shift; managed app services if the application already suits them. Database: self-managed on the VM is simpler and cheaper; a managed service such as Amazon RDS or Azure Database for PostgreSQL handles patching and point-in-time recovery for a higher monthly cost. Files: local disk for a single server, object storage such as S3, Azure Blob or MinIO if more than one server needs them. Operating system: start on a current LTS release such as Ubuntu 24.04, not the version the old server happened to run. Accounts and ownership: the cloud account, billing and root credentials belong to your organisation, with multi-factor authentication on every admin login. Resist the urge to modernise everything at once. Moving a PHP site from shared hosting to a VM, upgrading PHP from 7.4 to 8.3 and rewriting the deployment pipeline in the same weekend multiplies the things that can break. Move first with as few changes as possible, then improve in separate, smaller steps. The one exception is unsupported software: PHP 8.1 and older no longer receive security fixes, and PHP 8.2 stops receiving them at the end of 2026, so plan that upgrade into the project rather than carrying an unpatched runtime to a new home.
Write the target down as code or a short document: instance size, firewall rules, open ports, where backups go. It becomes the runbook for rebuilding the server later.
3. Rehearse the move on a copy Build the new environment, copy the data across and run the application there under a temporary hostname before anyone touches DNS. This rehearsal shows how long the data copy takes, which is the number your downtime window depends on.
For a typical PHP and MySQL site, the copy looks like this. The --single-transaction flag gives a consistent dump of InnoDB tables without locking the site, and rsync can be re-run later to send only what changed.
# On the old server: consistent MySQL/MariaDB dump
mysqldump --single-transaction --routines --triggers \
-u appuser -p appdb | gzip > appdb.sql.gz
# From the new server: copy files, preserving permissions
rsync -avz --delete \
olduser@old.example.com:~/public_html/ /srv/app/public/
# Restore into the new database
gunzip < appdb.sql.gz | mysql -u appuser -p appdb
# PostgreSQL equivalent
pg_dump -Fc -f appdb.dump appdb
pg_restore --no-owner -d appdb appdb.dumpThen test the copy. Log in as a real user, submit a form, upload a file, trigger an outgoing email and run any scheduled job by hand. Check the error log. Watch for absolute paths and old hostnames stored in the database or configuration files; WordPress and many CMSs store the site URL in the database.
If you move from Apache to NGINX, .htaccess rules no longer apply. Every redirect and rewrite has to be translated into the NGINX server block, and missing ones show up as 404s or broken SEO redirects.
4. Prepare DNS and the rollback plan DNS changes are only as fast as the TTL on the records you change. If the A record has a TTL of 86400 seconds, some visitors will keep reaching the old server for up to a day. Lower the TTL on the records you will change to 300 seconds at least one full old-TTL period before the cutover, so the short value has spread by the time you need it.
# Ask the authoritative server for the configured TTL
# (a public resolver shows the remaining cached TTL)
dig +noall +answer example.com A @ns1.your-dns-host.com
dig +noall +answer www.example.com CNAME @ns1.your-dns-host.com
# After the change, confirm from a public resolver
dig @1.1.1.1 +short example.com AThe rollback plan is easy to forget. It answers three questions: what condition means we roll back, who decides, and how. Usually it means pointing DNS back at the old server, which still works because nobody touched it. If users wrote data to the new system before the rollback, decide in advance whether that data is copied back or accepted as lost.
5. Cut over Pick a quiet window, tell users, and follow a written sequence.
Put the old application into maintenance mode or read-only, so no new data is written there. Run the final database dump and the final rsync. Because files were copied during the rehearsal, this pass is short. Restore and run quick checks on the new server: row counts on key tables, a test login, a test order or form. Have TLS certificates ready. Let's Encrypt HTTP-01 validation only succeeds once DNS points at the new server, so issue certificates in advance with DNS-01 validation, or immediately after the DNS switch. Update DNS records and confirm the new answer from public resolvers. Switch on scheduled jobs on the new server, and make sure they are off on the old one, so nothing runs twice. Watch the logs and error rates for the first hour. 6. The first two weeks after Keep the old server running, unchanged, for at least two weeks. Some resolvers ignore low TTLs, some integrations call the old IP directly, and some problems only appear on the monthly payroll run or at the end of term. The old system is your fallback and reference copy.
During this period, confirm the things that prove the new setup is complete: backups run and a restore from off-server storage succeeds, monitoring alerts reach a person, certificates show a renewal date, and the cloud bill matches the estimate. Set a budget alert in the provider console in the first week. A forgotten large instance or a snapshot policy without expiry is the most common source of a surprise bill.
Only then cancel the old hosting, after exporting anything you may need later, such as logs or mail archives.
Cloud migration checklist Every job the old system does is listed, including cron, email, DNS and IP allow-lists. Email has its own plan and MX records will not break when hosting is cancelled. The cloud account and credentials belong to your organisation, with MFA on admin logins. Target design is written down: size, region, open ports, database, backups. A full rehearsal ran under a temporary hostname and the copy time is known. DNS TTLs were lowered well before cutover. Rollback trigger, owner and steps are written down. Scheduled jobs run on exactly one server after cutover. A backup has been restored from off-server storage on the new setup. Monitoring and a budget alert are in place before the old system is switched off. If several of these are unclear, or the system holds data that cannot be lost, such as student records, patient data or orders, it is worth having someone who has done the move before plan the cutover with you. The steps do not change; what experience adds is knowing where your system is likely to push back.
Infigini IT Services · 11 Kanwali Road, Dehradun 248001, India · info@infigini.com · +91 95684 87789