VPS Migration Plan for Agencies in 2026 (No Client Surprises)

A VPS migration rarely goes sideways because of rsync. It goes sideways because the client signs off, you move the site, and then email stops delivering, DNS clings to the old IP, or a missed cron job quietly kills order confirmations. A VPS migration plan is an operations plan: who approves what, what gets tested, what “stop and roll back” looks like, and what you watch after the switch.

Hostperl works with New Zealand and APAC agencies that migrate in batches—five brochure sites one week, then a high-traffic WooCommerce build the next. This is written for that pace. It’s not a click-by-click tutorial. It’s an editorial checklist your team can run so migrations feel boring (in the best way).

Why a VPS migration plan looks different for agencies

Agencies don’t carry the same risk profile as a single business moving one site. You’re juggling stakeholders, shared credentials, mixed stacks, and three different versions of “done.” Your plan needs to protect:

• Client trust: no surprise downtime, no “our email vanished” calls, no Monday-morning panic.
• Delivery capacity: migrations that don’t eat the team for days when you still have projects shipping.
• Repeatability: a process you can reuse even with odd DNS setups, legacy plugins, or messy mailboxes.

If you’re moving from shared hosting into a faster, isolated environment, confirm the reason in plain business terms first. If you’re seeing intermittent 503s, CPU throttling, or slow admin screens, match the symptoms against hosting upgrade warning signs in 2026. That framing turns “we changed hosts” into “we fixed a bottleneck.”

On the infrastructure side, agencies usually choose a VPS for predictable resources and clean boundaries between client environments. Hostperl’s Hostperl VPS fits this workflow well: you can size per site, keep staging separate, and scale without shifting platforms again.

VPS migration plan: scope it like a contract, not a ticket

Before you touch DNS or copy a database, write the scope in plain language. If it’s not written down, it will be debated later—usually after something breaks.

These are the gaps that cause the most pain:

• “Website” isn’t only web files. It includes cron jobs, background workers, cache layers, object storage keys, and .env secrets.
• Email is usually the real outage. Clients tolerate a short cutover. They don’t tolerate a broken mailbox.
• DNS ownership is messy. The registrar, the DNS host, and the person with the login are often three different parties.
• SSL issuance can stall cutovers. If you depend on HTTP validation and the site sits behind temporary auth, you can block Let’s Encrypt.

Use a one-page migration brief per client. Keep it tight, but complete:

• Domains and subdomains (www/non-www, API subdomain, app subdomain)
• DNS host and registrar
• Email location (same host vs third-party)
• Databases and size
• Runtime (PHP version, Node/Python if applicable)
• Traffic patterns (peak hours in NZ/AU vs US/EU)
• Success criteria (what the client will accept as “done”)
• Rollback trigger (what forces a revert)

If the client expects a big speed jump from leaving shared hosting, set expectations early. A VPS gives you isolation and tuning headroom, but it won’t fix slow plugins or bad queries by itself. Bring your baseline, and use Shared Hosting vs VPS Performance in 2026 as a neutral explainer so everyone understands what’s changing—and what isn’t.

Build a staging run that proves the move will work

Teams that migrate cleanly treat staging as a dress rehearsal. Not a bonus. Not “if we have time.” It’s where you find the sharp edges while nobody is refreshing the live site.

A useful staging run answers five questions:

• Will it boot? PHP version, extensions, permissions, paths, and web server rules match what the app expects.
• Will it send? Contact forms, order emails, and password resets behave correctly.
• Will it schedule? Cron jobs and scheduled tasks actually run on the new server.
• Will it integrate? Payment gateways, webhooks, API callbacks, and SSO redirect URIs are updated.
• Will it stay stable? No runaway memory usage and no repeating 502/504s under normal browsing.

Two small habits save a lot of support time:

• Use a hosts-file preview for client signoff. Your team can validate the new server without touching public DNS.
• Write down config file locations. Agencies inherit mixed stacks. Knowing where to look avoids hours of hunting later (for example: /etc/nginx/nginx.conf, /etc/apache2/sites-available/, /etc/php/8.3/fpm/pool.d/ on Ubuntu).

If Apache tuning is part of the move, tune during staging with real traffic in mind, not guesswork. Keep Apache performance tuning on Ubuntu VPS handy while you right-size workers beyond the defaults.

Email and DNS: the two places agencies get burned

Most “the migration failed” stories are actually two separate problems: DNS caching and mailbox continuity.

DNS timing that works in the real world

DNS doesn’t flip like a light switch. Resolvers cache records, and some networks ignore low TTLs entirely. Plan for mixed routing for 24–48 hours after cutover.

• Lower TTL in advance (ideally 24–48 hours before). Don’t drop it five minutes before and expect it to matter.
• Keep the old host serving during the overlap window so late-resolving visitors still get a working site.
• Plan for both A/AAAA and CNAME chains. Change one and forget the other, and you’ll get inconsistent routing.

If you’re also changing nameservers (not just A records), treat it as a bigger cutover. Nameserver changes can surface old glue records and cached delegation data. For live sites, reduce moving pieces: migrate the site first, then consolidate DNS later if you still want to.

Email continuity without “mailbox drama”

Don’t assume email “moves with the site.” Decide early whether email stays put or moves with the hosting.

• If email stays with Microsoft 365 / Google Workspace: keep MX, SPF, DKIM, and DMARC pointed there. Your web migration should not touch email DNS.
• If email is currently on the old host: you need a mailbox plan (IMAP sync, forwarders, catch-alls, aliases, filters, plus devices that cache passwords).

For a client-friendly checklist, align your workflow with Email Hosting Migration Checklist for 2026. If you’re moving email onto a VPS, write the deliverability plan (SPF/DKIM/DMARC) and get signoff before cutover. Hostperl’s support team sees too many “we’ll fix it after” migrations that turn into invoice emails landing in spam.

If you want to keep email simple for smaller clients, it’s common to leave email on shared hosting while moving the site to a VPS. To weigh the tradeoffs, read Email Hosting on VPS vs Shared Hosting in 2026 and decide based on responsibility, not feature lists.

Cutover day: keep it calm, scripted, and reversible

Cutover isn’t the moment for heroics. It’s the moment for a short script everyone follows.

Use a cutover runbook with timestamps. A simple table in the project doc is enough. Include:

• T-60 minutes: confirm backups exist and are restorable (files + database). Confirm you can access DNS.
• T-30 minutes: freeze content changes (or put the site into a controlled maintenance mode if it’s dynamic).
• T-15 minutes: final sync of files and database. Verify database credentials on the new server.
• T-0: change DNS (or swap proxy upstream if you’re using a reverse proxy). Record the exact changes.
• T+15 minutes: smoke tests from multiple networks (mobile, office, VPN). Confirm checkout/contact forms.
• T+60 minutes: monitor error logs, PHP-FPM status, and resource usage. Watch for spikes.

One operational habit that pays off: define a rollback decision point. Example: “If checkout fails for more than 10 minutes, roll back DNS and regroup.” Rollback isn’t defeat. It’s how you protect revenue and trust.

If you want a deeper look at downtime mechanics (including the ugly edge cases like cached A records), our editorial on Website Migration Downtime Strategy for Hosting in 2026 pairs well with this agency-focused plan.

Post-migration checks that catch the quiet failures

Most teams test the homepage and call it done. That’s how you end up with broken search, failed form submissions, missing PDFs, and a “why did leads drop?” email two weeks later.

Use a short checklist that matches how the site makes money:

• Transactions: checkout, payment callbacks, order emails, refund emails.
• Lead flow: forms, CRM integration, spam protection, autoresponders.
• SEO basics: robots.txt, sitemap, canonical URLs, redirects.
• Media and downloads: PDFs, large images, video embeds.
• Background jobs: WP-Cron vs real cron, scheduled reports, imports.

On the server side, two quick checks prevent common post-cutover issues:

• Log growth: a small misconfig can fill disks fast. If you haven’t already, set rotation. For Ubuntu, use Set Up Logrotate for Server Logs on Ubuntu VPS.
• Firewall sanity: don’t leave staging holes open. Lock inbound ports to what you need (typically 22, 80, 443, and mail ports only if you run mail). See Set Up UFW Firewall Rules on Ubuntu VPS if you’re on Ubuntu.

If the site runs a database-heavy CMS, schedule a week-two performance review. That’s usually when slow queries start showing up. Instrument it with the MySQL Slow Query Log on Ubuntu VPS, then fix the bottlenecks instead of throwing CPU at the problem.

Client handover: the piece most agencies under-document

A successful migration should lower your future support load, not raise it. That only happens if you explain the new hosting setup clearly and leave a paper trail.

Ship a simple handover pack (PDF or shared doc) that covers:

• Where the site is hosted now (provider, plan, server location if relevant)
• Who owns DNS and where it’s managed
• Backup schedule and retention (and what is not covered)
• How to request changes and what counts as urgent
• Renewal dates for domains, SSL, and paid plugins

This is also where you set the commercial boundary: are you selling “hosting” as a line item, or hosting under the client’s account? If you do ongoing management, keep responsibilities explicit. Hostperl customers often run agency-managed stacks on a VPS and keep simpler sites on shared hosting to control costs. For lightweight brochure sites that don’t need custom tuning, Hostperl shared hosting can be a sensible landing zone while you reserve VPS for clients that need isolation or custom configurations.

Common pitfalls we see in support (and how to prevent them)

These show up in real tickets after agency cutovers. Deal with them upfront and your “aftercare” workload drops fast.

• Mixed-content warnings after HTTPS: old hard-coded http:// links in themes or page builders. Fix before launch.
• Forgotten subdomains: dev., staging., assets., api. still pointing to the old host.
• Image/file permissions: uploads failing because ownership differs across hosts.
• Missing PHP extensions: common with older apps (intl, imagick, gd). Confirm during staging.
• Outgoing email blocked or rate-limited: if you move to sending from the VPS, plan deliverability and warm-up. Don’t blast newsletters on day one.
• Backups not tested: “We have backups” is not the same as “We restored a backup into staging and it worked.”

If you want a structured way to discuss backups during migrations, align with RPO/RTO targets and document them. Hostperl’s editorial on Hosting Backup Strategy in 2026 helps you explain those tradeoffs to clients without vague promises.

Summary: make migrations repeatable, not heroic

A strong VPS migration plan keeps your agency out of firefighting mode. Scope the work like a contract, rehearse in staging, treat DNS and email as first-class systems, and run cutover from a script with a clear rollback point. The win isn’t “site moved.” It’s “client operations stayed intact.”

If you’re moving multiple client sites this quarter, standardise your runbook and your hosting baseline. Consistency removes the one-off fixes that quietly chew through margins.

FAQ

How long should a VPS migration take for a typical client site?

For a standard CMS site, plan 3–6 hours of hands-on work plus a 24–48 hour overlap window for DNS caching. Ecommerce or membership sites usually need a longer freeze window and more testing.

Should we migrate email at the same time as the website?

Only if you have a clear mailbox migration method and time to support devices after the cutover. Many agencies keep email where it is and migrate the website first to reduce moving parts.

What’s the safest way to reduce downtime during cutover?

Lower DNS TTL 24–48 hours in advance, keep the old host online during propagation, and do a final content sync right before switching. Have a rollback trigger defined before you start.

Do clients need a control panel on the VPS?

Not always. If your agency manages the server, clients often just need a clear handover doc and a support process. If clients will manage their own domains, email, or files, a panel can reduce support load.

What should we monitor in the first 24 hours after migration?

Error logs (web server and PHP), disk space, CPU/memory, transaction flows (forms/checkout), and email sending if it changed. A quick review the next morning catches “quiet failures” before the client does.