Website Migration Checklist for Shared Hosting in 2026

Most shared hosting moves don’t fail because “the website” breaks. They fail in the supporting systems: DNS cutovers, mailbox delivery, SSL details, and the one cron job nobody remembered until it stopped running. This website migration checklist for shared hosting is written from the provider side—what our Hostperl support team runs into during real migrations, and what you can do to keep cutover day quiet.

This stays practical: what to confirm before you touch DNS, what to export, what to test, and the common mistakes that create downtime or missing email. Whether you’re moving a small business site, an agency client, or a WordPress store, the workflow is the same.

Why shared hosting migrations go wrong (and how to prevent it)

Shared hosting still fits plenty of sites in 2026 because the platform work—patching, basic monitoring, mail routing, and web server tuning—sits with the host. The trade-off is predictability: you’re moving into a more structured environment. That structure improves stability, but it also exposes assumptions that worked on “a random VPS” or an old cPanel box full of one-off tweaks.

• DNS is cut too early and visitors bounce between old and new while you’re still testing.
• Email is forgotten so the site looks fine, but mail bounces or lands in spam for 24–72 hours.
• SSL is “active” but incomplete (wrong hostname, missing intermediate chain, mixed-content warnings).
• Hidden dependencies like PHP version changes, missing extensions, or permission quirks trigger 500 errors after cutover.

If you take one thing from this: don’t treat the move as a single switch. It’s four coordinated cutovers—website, database, DNS, and email.

Pre-migration inventory: what you need before you move anything

Before you export a single file, capture the current “source of truth.” It prevents the most common support ticket we see: “It worked yesterday—what changed?” (What changed is the move, and nobody wrote down the old settings.)

Collect these details from the old host

• Domain list: primary domain, www/non-www behaviour, all parked/addon domains, and subdomains.
• DNS records: A/AAAA, CNAME, MX, TXT (SPF/DMARC), and any verification records for Google/Microsoft, Stripe, Xero, etc.
• Email setup: mailboxes, forwarders, catch-all rules, autoresponders, plus any external mail services.
• App stack: CMS/plugin versions, PHP version, required PHP extensions, cron jobs, and custom rewrite rules.
• Data: databases, database users, and any scheduled exports or backups you rely on.

Quick “don’t skip” checklist

• Take screenshots of your current DNS zone and mailbox list.
• Export a list of cron jobs (even if you’re sure you “don’t have any”).
• Write down your current PHP version and memory_limit.
• Confirm whether your site sends mail via PHP mail(), SMTP, or an API service.

Hostperl tip: for most brochure sites, blogs, and standard WordPress builds, Hostperl shared hosting is the easiest landing zone because the control panel, email, SSL, and backups live together. If you’re running heavier workloads or a custom stack, a Hostperl VPS gives you control over PHP-FPM, caching layers, and system packages.

Lower DNS TTL before the cutover (48–72 hours ahead)

DNS TTL decides how long resolvers cache your records. If your TTL is 14,400 seconds (4 hours) and you need to correct an IP after cutover, you may end up waiting. Agencies feel this most when they’re moving multiple client domains in a single evening.

A safe approach:

• 48–72 hours before migration: lower TTL for A/AAAA and MX records to 300 seconds (5 minutes).
• After migration is stable: raise TTL back to 3600–14400 seconds to reduce DNS query volume.

If your domain uses cPanel DNS tools, our guide on configuring DNS records in cPanel shows exactly where the records live and what you should avoid changing by accident.

Pick a migration window that matches how your customers behave

Migrations on shared hosting aren’t complicated, but timing still matters. If you run ecommerce, don’t schedule a move during ad campaigns, payday spikes, or newsletter sends. For many NZ/APAC businesses, a late evening NZT cutover reduces customer impact while still keeping you inside useful support overlap if you need help validating settings.

Plan for three windows:

• Prep window: copying data, staging, and testing with no DNS changes.
• Cutover window: the DNS change and the final sync.
• Stabilisation window: fix edge cases (forms, redirects, missing images), verify mail flow, and monitor.

Move the site content the way your platform expects

The best migration method depends on what you’re moving and where you’re landing. On shared hosting, aim for boring and predictable: correct ownership, correct docroot, and no mystery symlinks or hard-coded paths.

WordPress

• Copy wp-content/ (themes, plugins, uploads).
• Export/import the database and update wp-config.php DB credentials.
• Search/replace URLs if the domain changes (http→https, old domain→new domain).

Custom PHP sites

• Confirm your new PHP version supports your code (especially older frameworks).
• Carry over .htaccess rules carefully; remove server-specific rules you don’t need.
• Check file permissions—shared hosting should not require 777 anywhere.

Static sites

• Copy site files and confirm caching headers and redirects behave as expected.
• If you used a build pipeline before, ensure the deployed output is what you’re copying.

Common pitfall: hard-coded references to the old server path, e.g. /home/olduser/public_html. These show up in custom scripts and image processors. If images suddenly break after migration, this is often the reason.

Database migration: avoid character set and collation surprises

Databases are where migrations quietly corrupt data: emojis get truncated, accented text turns into “?”, or imports fail due to collation mismatches. In 2026, you should strongly prefer utf8mb4 with a modern collation for MySQL/MariaDB.

What to verify before import

• DB engine/version: MySQL vs MariaDB differences can affect strict SQL mode behaviour.
• Charset: confirm tables are utf8mb4, not legacy utf8.
• Users/permissions: create the DB user cleanly and grant only what’s needed.

A safe export approach (if you have shell access)

Not every shared hosting plan includes SSH, but many migrations start from a VPS or an older dedicated server. This dump style reduces import surprises:

mysqldump --single-transaction --routines --triggers --default-character-set=utf8mb4 \
  -u DBUSER -p DBNAME > db.sql

If you don’t have shell access, use your current control panel’s export tool and confirm it exports the full database (not just selected tables).

Email: the part that hurts most if you forget it

Website downtime is obvious. Email failure is worse because it’s quiet. Messages bounce, invoices vanish, and you only hear about it days later.

Decide what happens to email before you migrate:

• Email stays with the old provider: migrate only the site; keep MX records unchanged.
• Email moves to Hostperl: migrate mailboxes and switch MX to the new host.
• Email uses Microsoft 365 / Google Workspace: verify SPF/DMARC and keep MX pointing to Microsoft/Google.

If you’re moving email into cPanel, you’ll usually set up forwarders, create mailboxes, and tune spam filtering on day one. Our cPanel reference on setting up email forwarding in cPanel covers the patterns we see most: sales@ to multiple recipients, role-based addresses, and “keep a copy” setups.

For delivery issues during or after the move, keep our email hosting troubleshooting checklist for 2026 nearby. It’s organised around the real culprits: wrong MX, missing DKIM, SPF that’s too strict, and outbound SMTP blocks caused by misconfigured apps.

Mail migration reality check

• Mailbox content doesn’t move just because your website moved. Plan an IMAP migration if users need their history.
• Autodiscover settings matter for Outlook. Document what changes, and expect some end-user reconfiguration.
• Contact forms may break if they send through PHP mail() and the “From” address doesn’t match the domain’s policy.

SSL and HTTPS: don’t wait until after DNS

You want HTTPS working before the public cutover. If you wait, the first visitors see certificate warnings and your SEO tools start flagging coverage issues. On shared hosting this is usually straightforward, but the details still matter.

Pre-cutover SSL checks

• Certificate covers both example.com and www.example.com if you use both.
• Your site forces one canonical hostname (www or non-www) with a 301.
• Mixed content is resolved (http image/script URLs updated).

If you’re on a VPS and handling SSL yourself, Certbot auto-renewal keeps things predictable; see SSL certificate auto-renewal with Certbot on Ubuntu VPS.

Staging and verification: how to test without breaking the live site

The smoothest migrations are boring because you tested before DNS changed. You have a few safe options:

• Temporary URL (if provided by your control panel/host): fast, but watch for hard-coded absolute URLs.
• Hosts file override: point your own computer to the new server IP while everyone else stays on the old host.
• Staging subdomain: e.g. staging.example.com, protected with basic auth while you verify.

During verification, don’t stop at the homepage. Test the paths that make you money and the flows customers rely on.

Launch readiness checklist (what we test in support)

• Forms: contact, quote, checkout, newsletter signup.
• Transactional email: order confirmation, password reset, enquiry receipt.
• Media: image thumbnails, PDF downloads, embedded videos.
• Admin logins: WordPress / Magento / custom admin area.
• Performance basics: Time to First Byte feels normal; pages don’t “hang” waiting on a remote service.
• Redirects: old URLs redirect cleanly; no redirect loops.

DNS cutover: do it in a controlled order

DNS cutover is where people rush. Don’t. Follow an order that limits surprises and makes rollback easier.

1. Freeze site changes on the old host (content edits, plugin updates, orders) if possible.
2. Final sync of files and database (the delta since your initial copy).
3. Switch A/AAAA records to the new server IP.
4. Switch MX only when you’re ready for email to land on the new host (if moving email).
5. Verify live traffic, logs, and email delivery after propagation starts.

Propagation in 2026 is fast for many resolvers, but it’s not instant. Some users will still hit the old site for minutes to hours depending on their ISP resolver behaviour and cached TTL.

Post-cutover monitoring for the first 24 hours

After cutover, focus on what customers notice first: broken forms, missing emails, and slow pages. Then move to the quiet failures—cron jobs and background tasks.

What to monitor immediately

• 404 spikes: often caused by missing rewrite rules or a docroot mismatch.
• 500 errors: PHP version mismatch, missing extensions, or wrong permissions.
• Email bounces: DMARC rejects, missing SPF, wrong MX, or app sending from unauthorised domains.

What to verify later that day

• Backups: confirm the new environment is backing up what you expect (site + database).
• Scheduled tasks: cron jobs, WordPress wp-cron behaviour, queue workers (if any).
• Search Console: check for crawl errors after the move, especially if HTTPS/hostnames changed.

If you’re coming from a VPS and you’re used to managing everything yourself, keep a simple runbook for rollbacks and quick checks. Our VPS migration checklist is written for that mindset and pairs well with this shared hosting version when you’re moving clients across different service tiers.

Real-world shared hosting migration traps we see at Hostperl

These are the repeat offenders—the “why is this happening?” tickets we see across thousands of moves. Check them early and you’ll avoid most unpleasant surprises.

1) The site loads, but admin actions fail

This usually comes down to PHP memory_limit, max_execution_time, or a missing PHP extension. You’ll feel it during plugin updates, image processing, or import tools.

2) Email works for receiving, but sending goes to spam

Most of the time SPF/DKIM/DMARC wasn’t updated for the new sender. If your website sends mail, make sure the sending method matches your domain policy. For VPS-based sending, our guide on Postfix SMTP authentication on Ubuntu covers authenticated relay, which is far more deliverable than unauthenticated outbound mail.

3) Images are missing only on some pages

This is often case sensitivity (Linux treats Image.jpg and image.jpg as different files) or an incomplete upload. It shows up frequently after moving from Windows-based hosting or from a system that silently “fixed” paths.

4) DNS looks right, but the wrong server answers

Usually the domain is using a different nameserver set than you expect, or there’s still a CDN/proxy in front (Cloudflare, Sucuri) pointing to the old origin.

5) The move worked… then broke a week later

That’s typically SSL renewal, a missed cron job, or a hard-coded IP address in an API allowlist. Set a 7-day “post-migration audit” reminder and do the boring checks.

Shared hosting vs VPS for migrations: which destination fits?

Some sites land perfectly on shared hosting. Others outgrow it—especially once you add membership plugins, WooCommerce, or an agency workflow where multiple people deploy changes.

• Choose shared hosting if you want a stable control panel experience, email included, and you don’t need OS-level changes. It’s ideal for WordPress, brochure sites, and small ecommerce with sensible traffic.
• Choose VPS hosting if you need specific PHP versions/modules, custom Nginx/Apache behaviour, background workers, or you want tighter performance isolation. Start with a right-sized plan and scale as you see real usage.
• Choose a dedicated server if you have high sustained load, compliance constraints, or you want predictable performance with no noisy-neighbour risk. This is common for busy stores, agencies hosting many client sites, and legacy apps that hate change.

If you’re unsure, start with shared hosting for simplicity and move up when the signals show up: slow admin, frequent resource limits, or recurring plugin timeouts. For that step-up path, managed VPS hosting is the most common upgrade because it adds control without turning every change into a sysadmin project.

FAQ: website migration checklist for shared hosting

How long does a shared hosting migration usually take in 2026?

For a typical small business site, expect a few hours for prep and testing, then minutes to hours for DNS propagation. If you’re migrating large mailboxes over IMAP, add a day or two depending on mailbox size and connection speed.

Should I move my email at the same time as my website?

Not always. If uptime matters, it’s often safer to migrate the website first and keep MX records unchanged. Then move email in a second, planned window after the site is stable.

What TTL should I set before the cutover?

Set A/AAAA (and MX if moving email) to 300 seconds about 48–72 hours ahead. After the migration settles, raise TTL back to 3600–14400 seconds.

How do I test the new site before DNS changes?

Use a temporary URL, a staging subdomain, or a local hosts-file override. The goal is to test forms, logins, checkout, and email sending without exposing the new server to all visitors yet.

What should I do after the move is “done”?

Do a 24-hour check (errors, email delivery, backups) and a 7-day check (SSL renewal, scheduled tasks, API allowlists). Most delayed issues show up in that first week.

Summary: a migration that stays boring is the goal

A good shared hosting move is mostly planning: lower TTL early, inventory DNS and email, test on the new host before you cut over, and treat mail as a first-class system—not an afterthought. Do that, and cutover becomes a controlled change instead of an emergency.

If you’re ready to migrate, Hostperl shared hosting fits sites that want simplicity, email, and a familiar control panel. If you need more isolation or custom server control, choose a Hostperl VPS hosting and we’ll help you map the cleanest path.