Moving hosting is a sequence of copying, testing and switching traffic. The safest plan starts before you cancel anything: identify what runs on the old account, make usable backups, prepare the destination and agree when new activity will move. A business site may contain more than its visible pages, especially if it handles email, orders, bookings or customer accounts.
This guide helps you organise the move and recognise when you need assistance. It does not promise zero downtime or assume that every site qualifies for a particular migration service. The exact process depends on your current software, access, account size and the destination environment.
1. Make an inventory before choosing a date
List every domain and website in the account, including subdomains and older installations still in use. Identify the software, database, storage use and required versions or extensions. Record scheduled tasks, redirects and integrations such as payment callbacks or form delivery. A copy of the home page will not reveal these dependencies.
Next, list mailboxes, forwarders and any external email service. Record where the domain is registered and which provider hosts its DNS. Confirm that you can access the relevant accounts and recovery email addresses. Ask the current provider about export options before the service expires or access is removed.
For a store, identify where new orders, stock changes and payment updates are written. You need a plan to prevent activity being split between two copies. Choose a quieter period and allow time for testing and correction, rather than scheduling the move immediately before a campaign or an important sales event.
2. Confirm the destination is suitable
Compare the requirements in your inventory with the new account. Check supported software, available resources, email needs and restore options. Multiple sites in one cPanel account share its resources; moving them together does not give each an independent allocation. An incompatible plugin or oversized account needs attention before a DNS switch.
WH4SA's general hosting pathway suits customers choosing and managing their own tools. The WordPress pathway prepares WordPress and Elementor Free for a new starting environment. Migrating an existing WordPress installation is a separate practical question: ask how your existing data and configuration will be handled instead of assuming that a prepared blank installation replaces a migration.
Agree who is copying files, importing databases, moving mail and changing DNS. If you ask for assistance, supply the software, approximate account size and current access method through an appropriate secure channel. Confirm the scope, eligibility, timing and any cost before relying on a migration arrangement.
Before moving a South African business website, inventory its files, database, mailboxes and DNS dependencies. Some services may stay with their current provider.
3. Back up the parts you will need
A dynamic website normally needs both its files and its database. Files may include uploads, themes, plugins and application configuration. The database may contain page content, settings, users and orders. A file-only copy can therefore look complete while missing the information needed to run the site.
Download an independent backup and check that it is readable. Record when it was created and what it contains. Keep it somewhere separate from the account being moved. For email, determine how mailbox content will be copied or exported; a website backup is not automatically an email migration.
cPanel's backup documentation distinguishes available backup and restoration workflows. A full account archive may require the hosting provider to restore it, rather than being something you can import yourself through every interface. Confirm the destination's accepted format before making that archive your only plan.
4. Prepare files and databases at the new host
Set up the correct domain or temporary testing arrangement and copy the site into the intended document root. Import the database using a suitable method, then update the application configuration to use the destination database credentials. Preserve file permissions and required server configuration, while checking for settings that refer specifically to the old environment.
Do not upload backup archives into a publicly accessible folder and leave them there. They can contain configuration or customer data. Keep staging copies appropriately restricted and remove temporary migration files when they are no longer needed. Store access information securely and avoid including passwords in ordinary support messages.
For WordPress, keep the domain unchanged where possible during a hosting-only move. If URLs must change, follow a method that understands WordPress data formats. Blind search-and-replace in an SQL file can break serialised values. The official WordPress migration guidance explains the different scenarios and why they need different steps.
5. Treat email as its own workstream
If email is staying with an external provider, preserve its MX and related authentication records. If mailboxes are moving, create the destination mailboxes and plan how historical messages will be copied. Confirm passwords or new account settings with authorised users through a secure process, then update their devices when appropriate.
Ask whether a final mailbox synchronisation will be needed after the first copy. New messages can arrive while migration work is underway. Keep the old service available long enough to check for mail delivered there during the transition, rather than assuming that changing a record instantly moves every sender to the new server.
Check shared addresses, forwarders and aliases as well as individual inboxes. Finally, review the website's sending configuration: a contact form or store may still refer to the old mail service even after ordinary mail applications are working correctly.
6. Test the destination before switching visitors
Use a testing method agreed with the destination host, such as a suitable preview arrangement or a local hosts-file override. A temporary URL may behave differently from the final domain, particularly for SSL, cookies and application URLs. Understand that limitation before treating a successful preview as complete proof.
- Open the home page and representative inner pages.
- Check images, downloads, menus and internal links.
- Sign in to the administration area and confirm content is present.
- Test forms and verify receipt at the destination inbox.
- Check redirects and HTTPS behaviour on the intended domain.
- For stores, test checkout safely and confirm integrations use the intended environment.
Use a payment provider's test mode where supported. Testing a store can send emails or create records, so plan it deliberately. Compare a recent order or content record with the original to establish how current the copied data is. Visual similarity alone does not establish database completeness.
Test the new environment before changing the records for the live .co.za domain. A copied homepage alone does not prove that the whole site works.
7. Plan the final data copy and DNS change
For a site that changes frequently, the first copy becomes outdated while testing takes place. Agree a final synchronisation or a controlled period when editing and transactions pause. The method depends on the application; do not attempt to merge two independently active store databases casually. Document what will happen if the final check fails.
Record the current DNS values before changing them. Decide whether you are updating website records or moving nameservers. With a nameserver change, ensure the destination DNS zone contains required email and verification records as well. A hosting move does not justify deleting unrelated records.
DNS caches obey record lifetimes, commonly called TTLs. Lowering a TTL ahead of a planned switch can help with subsequent cache expiry, but it does not erase copies already cached under an older value. Cloudflare's TTL documentation explains the principle. There is no universal instant propagation time to promise every visitor.
8. Check the live result and keep a rollback plan
After the switch, check the website from more than one connection and verify that requests reach the destination. Confirm SSL, forms, email and representative account actions. For an e-commerce site, inspect order and payment updates carefully. Monitor errors and available resources during normal activity rather than stopping at the first successful page load.
Keep the old hosting and backups available during an agreed observation period. A rollback may involve DNS and application data, not just pointing traffic backwards. New orders or edits on the destination must be considered before reverting, or you risk losing work that happened after the switch.
Only cancel the old service once the website, email and other dependencies have been accounted for. Check the old provider's cancellation and data-retention arrangements directly. Do not use cancellation as the first migration step.
DNS changes may reach visitors at different times. Keep the old service and recovery information until you have confirmed the move; zero downtime is not guaranteed.
Domain transfer is a separate decision
A domain transfer changes the registrar managing the registration. Hosting migration moves the website environment. You may connect your existing domain to new hosting without transferring its registration, or transfer the domain while keeping its current hosting. The two processes can be coordinated, but they are not interchangeable.
Read the domain transfer information if you also want to move registration management. Confirm the applicable requirements and renewal timing for your extension. Keeping these tasks separate in your checklist makes it easier to understand which change affects traffic and which affects domain administration.
When to pause and ask for help
Get assistance if you cannot obtain a usable backup, do not understand the DNS dependencies, have a large active database, or need to move sensitive live transactions without a clear synchronisation method. Provide a factual inventory and the result you need. A well-defined migration request is easier to assess than a general request to move everything, and it gives you a clearer basis for agreeing the next steps.