Move Website New Host Without Downtime: South African Guide 2026

When you need to move website new host without your business going dark, the single variable that controls whether the transition takes five minutes or 48 hours is something most guides skip: the DNS TTL window. If you manage your site through a website builder or managed CMS in South Africa, the steps below apply whether you are on WordPress, Joomla, or a plain HTML site. Done in the right order, a host migration is a planned maintenance event — not a gamble with uptime.

South African businesses have an extra layer to consider that most international migration tutorials miss: the POPIA Section 72 question. If your current host stores customer data on servers outside South Africa, switching to a local provider (Xneelo, Afrihost, 1Grid, HostAfrica) eliminates the transborder transfer documentation you would otherwise need to maintain. That alone is worth running through the checklist below.

Why South African Sites Outgrow Their Current Provider

The decision to move website new host is the right call when the pain of staying exceeds the effort of leaving — and three patterns recur reliably in the South African market.

Shared server overcrowding. Budget-tier plans often run on heavily shared infrastructure. When multiple sites compete for the same CPU and RAM, load spikes on a neighbour's site slow yours down regardless of your own traffic levels. The result shows up as inconsistent response times and crawl delays that compound into lost search visibility. See how page speed affects SA conversions for the full picture.

Support that can't keep pace. A hosting support queue with 48-hour ticket windows does not serve a business where a payment gateway failure costs sales per hour. Same-timezone SA support teams resolve critical issues faster — that is a structural advantage of local providers, not a marketing claim.

POPIA data residency. POPIA Section 72(1) lists several grounds on which a transborder data transfer is lawful — including substantially equivalent data protection in the destination country, data-subject consent, contract performance necessity, and others. Using any of those grounds requires documentation; identifying which applies to your situation is a legal question. When you move website to new hosting South Africa (a local provider with SA data centres), the Section 72 analysis disappears entirely — no transfer documentation needed at all.

Preparing for Cutover: The 48-Hour TTL Window

The single most important pre-migration action is also the one most often skipped: reducing your DNS TTL before you touch anything on the server side.

What TTL does. Every DNS record has a Time to Live value — a number that tells resolvers worldwide how long to cache your domain's IP address. A standard business site typically carries a TTL of 3,600–7,200 seconds (one to two hours).

When you update your DNS to point to a new server, resolvers only fetch the new value once the old cached version expires. At a default TTL, that wait stretches to two hours per resolver — and with millions of resolvers worldwide refreshing on different schedules, some visitors will still reach your old server hours after you believe you have switched. This is why you lower the TTL days before you move to new hosting, not on the day of cutover.

The pre-change sequence for .co.za domains:

Load-shedding as a timing factor. This is a practitioner consideration, not a technical requirement: scheduling your DNS cutover during a confirmed Eskom Stage 3+ load-shedding window means SA ISP infrastructure — including many resolvers — may be running on limited capacity. Plan your cutover for a stable power window if your audience is primarily South African. A quiet Tuesday morning before 09:00 is a better window than a peak-hour afternoon during scheduled outages.

Use a free propagation checker (whatsmydns.net or dnschecker.org) to monitor how the change is spreading across global resolvers in real time. For a full explanation of how DNS caching affects propagation speed, HOSTAFRICA's DNS propagation guide covers the mechanics clearly.

Move Website New Host: The 8-Step Process

To move website new host, the process follows a consistent sequence regardless of your platform. The WordPress version uses a migration plugin (Duplicator is a widely used free option); non-WordPress sites use FTP and phpMyAdmin directly. Both follow the same logical order.

Step 1 — Choose and set up your new SA hosting account

Sign up with your new provider before you do anything else. To move to new hosting provider South Africa, choose a provider with local data centres — this covers POPIA Section 72 compliance and gives SA visitors lower latency in one decision. Entry-level shared hosting from local providers runs from around R84–R99 per month (Afrihost and Xneelo both start in this range); managed VPS starts from approximately R1,199 per month with 1Grid.

Get your hosting panel credentials and your new server IP address. If your provider offers a free migration service, flag that you will be migrating an existing site before starting. Match the plan to your current resource usage, not your peak aspirations.

Step 2 — Back up your site in two locations

Download a complete backup — all site files plus a full database export — and store copies in two separate places (your local drive plus cloud storage). This is your safety net if anything goes wrong during the transfer. To move WordPress to new hosting, a plugin like Duplicator handles both the file archive and database export in one step. For cPanel-hosted sites, the built-in backup tool covers both.

Step 3 — Create the database on the new server

Log into your new hosting panel and create a fresh MySQL database. Create a database user with full privileges on that database. Note the database name, username, and password — you will need them during the import step. This is a two-minute task in cPanel or Plesk.

Step 4 — Upload your site files

Transfer your site files to the new server via FTP (FileZilla is the standard tool) or through your hosting panel's file manager. For WordPress, your entire public_html folder goes across. This step takes longer on large sites — a 1GB site on a solid business connection will transfer in 20–30 minutes.

Step 5 — Import the database

Use phpMyAdmin on the new server to import your database backup. Update the wp-config.php (WordPress) or equivalent configuration file to point to the new database credentials you set in Step 3.

Step 6 — Test the migrated site using your hosts file

Before touching DNS, add a temporary entry to your computer's hosts file that maps your domain to the new server's IP address. This makes your machine resolve the domain to the new server while everyone else still hits the old one. Browse every page, submit a test form, and confirm your SSL certificate is active. Fix any broken paths or configuration issues here — not after the DNS has switched and real visitors are affected.

Step 7 — Update DNS at your registrar

Log into your domain registrar (the place where you manage your domain registration and DNS settings) and update your nameservers or A record to point to the new host. You lowered your TTL 48 hours ago, so propagation should complete within 15–30 minutes for most resolvers — though full global propagation for .co.za nameserver changes can still take up to 48 hours.

Step 8 — Verify and close the old account

Keep the old hosting account active and serving traffic for at least 72 hours after your DNS update. Check your analytics to confirm traffic is hitting the new server. Run the post-migration checklist below before cancelling the old plan. Cancelling too early means visitors still resolving via old records hit a dead server.

Staging Test: Verifying the Migrated Site Before Cutting Over

Testing the migrated site via your local hosts file is the step most DIY migrations skip — and the one that catches the largest share of configuration errors before they affect live visitors. Broken redirects, missing SSL, misconfigured database credentials, and unresolved media paths all surface here rather than in front of real customers.

Add a line to your hosts file in the format NEW.SERVER.IP.ADDRESS yourdomain.co.za. On Mac and Linux, the hosts file is at /etc/hosts; on Windows, at C:\Windows\System32\drivers\etc\hosts. Save and flush your DNS cache. Now when you open your browser and navigate to your domain, your machine bypasses the live DNS and connects directly to the new server.

What to test before going live:

• Every major page type — homepage, category, product, contact, blog post
• All contact and enquiry forms (test submissions should reach the right inbox)
• SSL certificate — the padlock should show; mixed-content warnings need fixing now
• Payment gateways if you run an ecommerce site — check that PayFast, Peach Payments or Yoco test transactions complete
• Redirect chains — any SEO redirect rules you had on the old server need to be re-applied on the new one
• Analytics and tracking scripts — confirm GA4 and any marketing pixels are firing correctly

When the hosts file test passes across all critical paths, remove the hosts file entry and proceed to the DNS update. Do not skip the hosts file test under time pressure — that is when mistakes become incidents.

Post-Migration Verification Checklist

The 72 hours after DNS cutover are when the website host migration without downtime either consolidates or unravels — these are the checks that confirm a clean outcome.

Keep a record of your old server's IP address and login credentials for at least 30 days after migration. Edge cases — a forgotten cron job, a backup script pointed at the old IP, a legacy API integration — surface weeks later more often than they do in the first 72 hours.

DIY or Professional Migration: An SA Decision Table

Whether you move website new host yourself or bring in a professional depends on site complexity, revenue dependency, and your technical access — not on confidence alone.

Why South African Businesses Choose Growth Pulse Media for Web Projects

Growth Pulse Media is led by Dirk van Greuning, who built and scaled a South African ecommerce business before founding the agency. That background means the team understands what a missed migration window or a broken payment gateway actually costs — not in theory, but in lost transactions and support calls.

All technical work is executed in-house. On web design and rebuild projects in South Africa, we handle hosting migrations, DNS setup, SSL configuration, platform integrations (PayFast, Peach Payments, Yoco), and the POPIA-aligned data handling decisions that come with moving to a new server — without handing pieces off to a third party and waiting for callbacks. For clients whose previous agency owned their hosting credentials, we have a structured process for credential recovery that prevents migration paralysis.

We maintain a limited client load specifically so that a project's most experienced hands — not a junior account team — are the ones running your DNS cutover. If you need a weekend migration window, we are available for it. On ongoing website maintenance retainers, hosting management and proactive migration support are built in.

Who This Migration Guide Is Not For

Frequently Asked Questions

How long does DNS propagation take for .co.za domains?

For .co.za domains, A record and CNAME changes propagate in 30 minutes to 24 hours; nameserver changes take up to 48 hours to resolve across all global DNS servers. The practical window you experience depends heavily on the TTL value your old host used. If you reduce your TTL to 300 seconds at least 48 hours before cutover, most resolvers will pick up the change within 15–30 minutes of the update. Without that pre-change, you are at the mercy of cached TTL values which may hold for another 24 hours.

Does POPIA affect which hosting provider I can use?

POPIA Section 72(1) lists several grounds on which a transborder data transfer is lawful — including substantially equivalent data protection in the destination country, data-subject consent, contract performance necessity, and others. Offshore hosting is not prohibited, but each lawful ground requires documentation and a legal assessment to confirm it applies. Using a South African hosting provider with local data centres removes this analysis entirely. Consult qualified legal counsel for specific compliance decisions; the above is a general summary, not legal advice.

Can I migrate my WordPress site myself or do I need a developer?

Most WordPress brochure sites under 500MB can move website new host using a free migration plugin like Duplicator without developer assistance. The technical work typically takes under one hour, excluding the DNS propagation wait — the biggest risk is getting the database credentials wrong at the import step, which the migration wizard walks you through. Where you need professional help: WooCommerce stores with live orders, sites over 5GB, any site where you do not personally hold the hosting panel credentials, or setups with custom server-side dependencies.

What should I check immediately after the migration completes?

In the first 72 hours, verify email routing (the most commonly broken component — MX records sometimes do not follow a migration), SSL validity across both www and non-www versions of your domain, analytics data flowing correctly in GA4, and your Google Search Console coverage report for any spike in 5xx server errors. If you run an ecommerce site, process a test transaction through your live payment gateway before declaring the migration complete. Keep the old hosting account active and do not cancel it until all of these checks pass.

Should I cancel my old hosting account immediately after switching?

No — keep the old account active for a minimum of 72 hours after your DNS update, and ideally for a full week. DNS propagation for .co.za nameserver changes can take up to 48 hours globally, and visitors resolving via old cached records will still reach the old server during that window. Cancelling immediately leaves those visitors hitting a dead server with no fallback. Wait until your analytics confirm traffic is landing consistently on the new server before cancelling the old plan.

Dirk van Greuning Founder, Growth Pulse Media

Founder of Growth Pulse Media and a specialist in South African search dominance. Dirk translates his experience in scaling South African businesses into high-velocity digital strategies for B2B and retail leaders. He writes about SEO, lead generation, and paid media from an operator's perspective — prioritising pipeline value over impressions.

Connect on LinkedIn