Moving a website from one hosting company to another may look like a simple process of copying files and changing DNS records. In reality, a hosting migration can involve website files, databases, email accounts, DNS records, SSL certificates, cron jobs, PHP configuration, subdomains, redirects, API integrations, security settings, and many other dependencies.

A poorly planned migration can cause website downtime, lost emails, database inconsistencies, broken forms, SSL errors, missing images, SEO problems, or even permanent data loss.

The safest migration strategy is:

Backup → Document → Prepare → Copy → Test → Synchronize → Switch DNS → Verify → Monitor → Retain Old Hosting → Cancel

The most important principle is simple:

Never terminate or modify the old hosting environment until the new hosting has been fully tested and DNS migration has completed successfully.

1. What Does Hosting Migration Mean?

Hosting migration means transferring a website and its associated services from one hosting provider or server to another.

For example:

Old Hosting Provider → New Hosting Provider

The domain name may remain with the same registrar. Changing hosting does not normally require transferring the domain registration.

A typical hosting environment may contain:

• Website files
• MySQL/MariaDB databases
• Email accounts
• DNS records
• SSL certificates
• Subdomains
• Addon domains
• Redirects
• Cron jobs
• PHP configuration
• Application configuration
• FTP/SFTP accounts
• DNS verification records
• SPF, DKIM and DMARC records
• CDN configuration
• API integrations
• Backup systems

Therefore, migration should be treated as an infrastructure migration rather than simply copying a website folder.

2. Do Not Confuse Hosting Migration with Domain Transfer

These are two different operations.

Hosting Migration

The website is moved from one server or hosting company to another.

Domain Transfer

The domain registration is transferred from one registrar to another.

You can migrate hosting without transferring the domain.

For example:

Domain Registrar: Company A
Old Hosting: Company B
New Hosting: Company C

The domain can remain registered with Company A while the website is moved from Company B to Company C.

Keeping domain transfer and hosting migration as separate operations can actually reduce migration complexity.

3. First Precaution: Never Cancel Old Hosting Before Migration

One of the biggest mistakes is cancelling the existing hosting immediately after purchasing new hosting.

Do not do this.

Keep the old hosting operational throughout the migration.

The recommended sequence is:

Old Hosting Active

↓

Take Backup

↓

Configure New Hosting

↓

Copy Website and Database

↓

Test New Server

↓

Perform Final Synchronization

↓

Change DNS

↓

Monitor New Hosting

↓

Keep Old Hosting Temporarily

↓

Cancel Old Hosting Only After Successful Verification

The old hosting acts as an important rollback option if something goes wrong.

4. Create a Complete Inventory Before Migration

Before copying anything, document the existing hosting configuration.

Check and record:

Website Information

• Primary domain
• Addon domains
• Subdomains
• Website document root
• CMS or application being used
• WordPress version, if applicable
• PHP version
• Database engine and version
• Required PHP extensions
• Custom configuration files

Database Information

Record:

• Database names
• Database users
• Database hosts
• Character sets
• Collations
• Database sizes

Do not store passwords in an unsecured migration document.

Email Information

Record:

• Email accounts
• Aliases
• Forwarders
• Distribution addresses
• Mailbox sizes
• Autoresponders
• SMTP settings
• IMAP/POP settings
• MX records
• SPF
• DKIM
• DMARC

Server Configuration

Check:

• PHP version
• PHP extensions
• memory_limit
• upload_max_filesize
• post_max_size
• max_execution_time
• max_input_vars
• cron jobs
• scheduled tasks
• redirects
• rewrite rules
• file permissions
• directory permissions

This inventory becomes the migration checklist.

5. Take Multiple Backups Before Starting

Never depend entirely on the hosting provider's backup.

Take an independent backup before making changes.

Ideally, maintain at least:

Backup 1: Existing hosting backup
Backup 2: Local/offline backup
Backup 3: Cloud or secondary storage backup

The backup should contain more than the public website directory.

Include:

• Website files
• Databases
• Email data where applicable
• SSL-related configuration where needed
• DNS zone records
• .htaccess
• wp-config.php or application configuration
• Cron jobs
• Subdomain configuration
• Redirect configuration
• Custom scripts
• Configuration files

For WordPress websites, also ensure that the backup includes:

wp-content/

and the complete WordPress database.

Without the database, the WordPress site is not fully backed up.

6. Export the Database Separately

Even when a complete hosting backup exists, creating a separate database export is recommended.

For MySQL or MariaDB, this could be:

mysqldump -u username -p database_name > database_backup.sql

A database backup may also be created using:

• phpMyAdmin
• Hosting control panel
• Backup utility
• SSH
• WordPress migration tools

After export, verify that the SQL file is not empty and appears to contain tables and data.

For a business-critical website, backup verification is as important as backup creation.

7. Save the Existing DNS Configuration

DNS is one of the most important parts of migration.

Before changing anything, record the complete DNS zone.

Important records include:

• A
• AAAA
• CNAME
• MX
• TXT
• SPF-related TXT records
• DKIM
• DMARC
• SRV
• CAA
• Verification records

Do not assume that changing hosting means every DNS record should be replaced.

For example, a company may use:

Website → Hosting Provider

while using:

Email → Google Workspace or Microsoft 365

Changing the website hosting should not accidentally replace the company's email MX records.

8. Be Extremely Careful with Nameserver Changes

There are generally two migration approaches.

Method 1: Keep Existing DNS and Change Website Records

If DNS is already hosted with the registrar, Cloud DNS provider, or another independent DNS service, you may only need to change the website's A/AAAA/CNAME records.

This often provides greater control.

Method 2: Change Nameservers

If the new hosting provider will also manage DNS, the domain's nameservers may need to be changed.

However, before changing nameservers, recreate all required DNS records on the new DNS service.

Otherwise services such as email may stop working.

9. Lower DNS TTL Before Migration

DNS records contain a TTL — Time to Live.

TTL determines how long DNS resolvers may cache a record.

Before a planned migration, lowering the TTL of the records being changed can help make the cutover faster.

For example, a record with a high TTL may remain cached for hours after you change it.

Where practical, reduce the TTL well before migration — ideally before the migration window — and allow the previous TTL enough time to expire.

After migration has stabilized, TTL can be increased again according to your normal DNS strategy.

10. Configure the New Hosting Before Changing DNS

The new server should be prepared completely while the existing website remains online.

Configure:

• Domain
• Subdomains
• Database
• Database users
• PHP version
• PHP extensions
• SSL
• Cron jobs
• Redirects
• File permissions
• Application configuration
• Email configuration, where required

Do not change DNS just because the files have been uploaded.

The new server should first be capable of running the website independently.

11. Copy Website Files to the New Server

Website files can be transferred using:

• SFTP
• SCP
• rsync
• SSH
• Hosting migration utilities
• Control panel backup/restore
• WordPress migration plugins

SFTP or SSH-based methods are preferable to unencrypted FTP where supported.

For large websites, rsync can be particularly useful because it supports efficient synchronization.

Example:

rsync -avz /source/path/ user@newserver:/destination/path/

The exact command and options should be adapted to the hosting environment.

12. Import the Database

Create the database and user on the destination server and import the database backup.

For example:

mysql -u username -p database_name < database_backup.sql

Then update application configuration if database credentials have changed.

For WordPress, check:

DB_NAME
DB_USER
DB_PASSWORD
DB_HOST

inside wp-config.php.

Never expose these credentials publicly or include them in support screenshots unnecessarily.

13. Check PHP Compatibility

A website may work perfectly on the old server but fail on the new one because of differences in the software environment.

For example:

Old Server:

PHP 7.4

New Server:

PHP 8.x

An outdated application, theme or plugin may not be compatible.

Check:

• PHP version
• MySQL/MariaDB compatibility
• PHP extensions
• ionCube Loader requirements
• memory limits
• execution limits
• upload limits
• file permissions
• deprecated PHP functions

Compatibility testing should happen before DNS cutover.

14. Test the New Website Before DNS Change

This is one of the safest migration techniques.

The new website should be tested while the public domain still points to the old server.

A common method is temporary hosts-file mapping on the administrator's computer.

For Windows:

C:\Windows\System32\drivers\etc\hosts

A temporary entry might resemble:

203.0.113.25 example.com
203.0.113.25 www.example.com

Here, 203.0.113.25 is an example/documentation IP address; use the actual destination server IP during a real migration.

This allows the administrator's computer to open the domain from the new server while normal visitors continue using the old server.

After testing, remove the temporary hosts-file entry.

15. Test More Than the Homepage

Opening the homepage successfully does not prove that migration is complete.

Test:

• Homepage
• Internal pages
• Images
• CSS
• JavaScript
• Contact forms
• Login
• Admin panel
• Search
• Database operations
• File uploads
• Downloads
• Payment gateway
• API integrations
• CAPTCHA
• SMTP
• Password reset
• User registration
• Scheduled jobs
• E-commerce checkout

For WordPress, also check:

• wp-admin
• Permalinks
• Plugins
• Theme
• Media library
• Forms
• Caching
• Security plugins

16. Plan for Database Changes During Migration

Static websites are relatively easy to migrate.

Dynamic websites require greater care.

Examples include:

• E-commerce stores
• Forums
• CRM systems
• Booking systems
• Membership websites
• Customer portals
• News websites
• WordPress sites receiving comments or registrations

Suppose the initial database backup is taken at 8:00 PM and DNS changes at 10:00 PM.

Any orders or updates created between 8:00 PM and 10:00 PM may be missing from the new server unless a final synchronization is performed.

Therefore, use one of these approaches:

Low-traffic site: Perform final database synchronization immediately before cutover.

High-transaction site: Use maintenance/read-only mode during final synchronization.

Advanced environment: Use database replication or a migration architecture specifically designed for live cutover.

17. Perform Final Synchronization Before DNS Cutover

After testing the new server, synchronize anything that changed since the first migration.

This may include:

• New database entries
• New uploads
• User-generated files
• Orders
• Form submissions
• Comments
• Product updates

A typical sequence becomes:

Initial Copy
↓
Configure
↓
Test
↓
Final File Sync
↓
Final Database Sync
↓
DNS Cutover

This greatly reduces the risk of data loss.

18. Take Special Care with Email

Email is one of the most frequently overlooked components of hosting migration.

First determine where email is hosted.

It may be:

• Same hosting server
• Google Workspace
• Microsoft 365
• Dedicated mail provider
• Another external service

If email is external, preserve the existing MX and related records unless the mail service itself is also being migrated.

Important records may include:

MX
SPF
DKIM
DMARC
Autodiscover
Verification TXT records

Deleting or incorrectly replacing these records can interrupt mail delivery or authentication.

19. Migrating Hosting-Based Email Accounts

If email is hosted on the old web server and must also move, create the mailboxes on the destination before cutover.

For example:

accounts@example.com
sales@example.com
support@example.com

Create the corresponding mailboxes, aliases and forwarders on the new mail server.

Historical mail may need to be migrated using IMAP synchronization or the provider's migration tools.

Before switching MX records, verify that the destination mail system can send and receive email correctly.

20. Protect Against Lost Email During DNS Propagation

During DNS transition, different mail systems may temporarily see different DNS information.

Therefore:

• Keep the old mail server operational
• Keep old mailboxes accessible
• Do not delete old email accounts
• Monitor both environments
• Verify incoming and outgoing mail
• Retain old hosting until transition is complete

For business email, mail migration should be planned separately from the web migration when possible.

21. Configure SSL on the New Server

The destination server should have a valid SSL/TLS certificate.

Verify:

https://example.com
https://www.example.com

Check for:

• Valid certificate
• Correct hostname
• Certificate chain
• HTTPS redirects
• Mixed-content errors
• HTTP-to-HTTPS redirect loops

Many hosting providers support automated certificate issuance, but SSL should still be verified after DNS cutover.

22. Check .htaccess and Rewrite Rules

Apache-based websites often depend heavily on .htaccess.

It may contain:

• Redirects
• Rewrite rules
• Security restrictions
• HTTPS enforcement
• PHP settings
• Caching rules

Make sure hidden files are included when copying the website.

A missing .htaccess file can cause:

• 404 errors
• Broken WordPress permalinks
• Redirect failures
• Security changes

23. Check File and Folder Permissions

Incorrect permissions can cause:

• 403 Forbidden errors
• Upload failures
• Plugin update failures
• Cache problems
• Security vulnerabilities

Typical Linux defaults are often:

Directories: 755
Files: 644

However, these are not universal requirements. Follow the application's and hosting provider's security model.

Avoid using 777 as a generic fix.

24. Verify Cron Jobs and Scheduled Tasks

Cron jobs do not automatically migrate just because website files were copied.

Examples include:

• Backup scripts
• Invoice generation
• Scheduled emails
• API synchronization
• Cleanup jobs
• Database maintenance
• Report generation

Document and recreate them on the destination server.

Also verify paths because a script that previously used:

/home/olduser/public_html/script.php

may now be located at:

/home/newuser/public_html/script.php

25. Check Hard-Coded Server Paths and IP Addresses

Applications sometimes contain absolute server paths or IP addresses.

Search configuration files and custom scripts for references to:

• Old server IP
• Old username
• Old home directory
• Old database hostname
• Temporary URLs
• Internal server paths

These should be corrected before production cutover.

26. Check Third-Party Integrations

A new server may have a different public IP address.

Third-party services may restrict access by IP.

Check integrations such as:

• Payment gateways
• APIs
• ERP integrations
• CRM integrations
• SMTP relays
• Webhooks
• CDN
• Cloud storage
• Firewall allowlists
• External database access

Update allowlists where required.

27. Do Not Change Too Many Things at Once

Migration is not the ideal time to simultaneously:

• Redesign the website
• Upgrade every plugin
• Change PHP major versions unnecessarily
• Change email provider
• Transfer domain registrar
• Change DNS architecture
• Replace the CDN
• Modify application code

The more variables changed simultaneously, the harder troubleshooting becomes.

A safer approach is:

Migration first → Stabilization → Upgrades later

28. Change DNS Only After Successful Testing

Once the new server is verified, update the required DNS records.

Depending on the architecture, this might involve changing:

• A record
• AAAA record
• CNAME
• Nameservers

Do not automatically change MX records when only the website is moving.

Record the old DNS values before modification so they can be restored quickly if necessary.

29. DNS Propagation Does Not Happen Everywhere at Once

After DNS changes, users may temporarily reach different servers because DNS information is cached by resolvers.

Some users may reach:

Old Server

while others reach:

New Server

This is another reason the old hosting should remain active.

The exact transition time depends on TTL, resolver caching, DNS architecture and other factors.

30. Verify DNS After Cutover

Check that the domain resolves correctly.

Useful commands include:

nslookup example.com

and:

nslookup -type=mx example.com

Where available, tools such as dig can provide additional DNS details.

Verify:

example.com
www.example.com
mail-related records
important subdomains

31. Monitor the Website Immediately After Migration

After cutover, monitor the website closely.

Check:

• HTTP status codes
• Server error logs
• PHP error logs
• Database errors
• CPU usage
• RAM usage
• Disk usage
• Response times
• SSL status
• Form submissions
• Email delivery
• Scheduled jobs

Pay special attention to HTTP errors such as:

403
404
500
502
503
504

32. Check SEO After Hosting Migration

A hosting migration should not significantly damage SEO when URLs and content remain unchanged and the migration is implemented correctly.

Preserve:

• URL structure
• HTTPS
• Canonical URLs
• robots.txt
• XML sitemap
• redirects
• www/non-www preference

Avoid accidentally introducing:

noindex

or blocking crawlers in robots.txt.

Also check that production pages return appropriate HTTP status codes.

33. Keep Old Hosting for a Safety Period

Do not cancel the old hosting immediately after DNS appears to be working.

For an ordinary website, keeping the old environment available for several days is prudent. For business-critical systems, a longer retention period may be appropriate depending on cost, transaction volume and rollback requirements.

During this period, compare:

• Website data
• Database
• Emails
• Forms
• Orders
• Logs
• Cron jobs
• DNS
• SSL
• Performance

The old environment provides a recovery option if a hidden problem appears later.

34. Create a Rollback Plan Before Migration

A professional migration should have a rollback strategy before DNS is changed.

Record:

Old Server IP
Old DNS Records
Old Nameservers
Old Database Backup
Old Website Backup
Old Email Configuration

If a critical problem appears, you should know exactly how to restore service.

A rollback should not depend on remembering the previous configuration.

Document it.

35. Recommended Zero-Downtime Migration Workflow

A safe workflow can be summarized as:

1. Audit Existing Hosting
        ↓
2. Record DNS and Server Configuration
        ↓
3. Take Complete Backups
        ↓
4. Verify Backups
        ↓
5. Prepare New Hosting
        ↓
6. Copy Website Files
        ↓
7. Export/Import Database
        ↓
8. Configure PHP/Application
        ↓
9. Configure SSL
        ↓
10. Configure Email if Required
        ↓
11. Configure Cron Jobs
        ↓
12. Test Using Hosts File/Staging
        ↓
13. Test Forms/APIs/Payments
        ↓
14. Perform Final Synchronization
        ↓
15. Change DNS
        ↓
16. Monitor Old and New Servers
        ↓
17. Verify Website/Email/SSL/DNS
        ↓
18. Monitor for Several Days
        ↓
19. Take New Production Backup
        ↓
20. Retire Old Hosting

This approach can minimize downtime substantially, although absolute zero downtime cannot be guaranteed for every hosting architecture.

36. Hosting Migration Checklist

Before Migration

☐ Confirm access to old hosting
☐ Confirm access to new hosting
☐ Confirm domain registrar access
☐ Record DNS records
☐ Record nameservers
☐ Record PHP configuration
☐ Record databases
☐ Record cron jobs
☐ Record email accounts
☐ Record subdomains
☐ Take website backup
☐ Take database backup
☐ Take email backup where required
☐ Verify backups
☐ Prepare rollback plan
☐ Lower relevant DNS TTL in advance where appropriate

New Server Preparation

☐ Configure domain
☐ Configure PHP
☐ Create database
☐ Create database user
☐ Upload files
☐ Import database
☐ Configure SSL
☐ Configure redirects
☐ Configure cron jobs
☐ Configure email if needed
☐ Check permissions

Testing

☐ Homepage
☐ Internal pages
☐ Images
☐ Admin login
☐ Database operations
☐ Contact forms
☐ SMTP
☐ Login/logout
☐ Upload/download
☐ Search
☐ API integrations
☐ Payment gateway
☐ Cron jobs
☐ SSL
☐ Redirects

Cutover

☐ Final file synchronization
☐ Final database synchronization
☐ Record exact cutover time
☐ Change required DNS records
☐ Keep old hosting running
☐ Monitor DNS resolution

After Migration

☐ Website loads correctly
☐ HTTPS works
☐ www/non-www works
☐ Email works
☐ Forms work
☐ APIs work
☐ Payment gateway works
☐ Cron jobs run
☐ Backups run
☐ Error logs checked
☐ Search engine access checked
☐ New production backup created
☐ Old hosting retained during safety period

37. Common Hosting Migration Mistakes

Mistake 1: Cancelling old hosting first

This removes the safest rollback option.

Mistake 2: Migrating files but forgetting the database

Dynamic websites depend heavily on their databases.

Mistake 3: Changing nameservers without recreating DNS records

This can break website, email and verification services.

Mistake 4: Accidentally changing MX records

This can interrupt business email.

Mistake 5: Testing only the homepage

Forms, APIs, login pages and scheduled tasks may still be broken.

Mistake 6: Forgetting SSL

The destination server requires valid HTTPS configuration.

Mistake 7: Ignoring PHP compatibility

Different PHP versions can cause application failures.

Mistake 8: Forgetting cron jobs

Scheduled processes may silently stop.

Mistake 9: Cancelling old hosting immediately after DNS change

DNS caching and undiscovered issues can make this risky.

Mistake 10: No rollback plan

Every important migration should have a documented recovery procedure.

38. Safest Hosting Migration Formula

The safest migration can be represented as:

Audit + Backup + Verification + Parallel Setup + Pre-Cutover Testing + Final Sync + Controlled DNS Cutover + Monitoring + Rollback Availability

The goal should not simply be to move the website.

The goal should be to migrate the complete service without losing:

Data + Email + Configuration + Availability + Security + SEO

Frequently Asked Questions — FAQ

1. Can I change hosting without transferring my domain?

Yes. Hosting and domain registration are separate services. You can keep the domain with the existing registrar and point its DNS to the new hosting environment.

2. Will changing hosting cause downtime?

It can, but careful preparation, pre-migration testing, final synchronization and controlled DNS cutover can greatly reduce downtime.

3. Should I cancel my old hosting before changing DNS?

No. Keep the old hosting operational until the new environment has been verified and the transition is complete.

4. Do I need to transfer my domain when changing hosting?

No. A domain transfer is normally unnecessary when only changing the web hosting provider.

5. What should I back up before migration?

At minimum, back up website files, databases, important configuration, DNS records, email data where applicable, cron jobs and application-specific settings.

6. Will my email stop working after changing hosting?

Not necessarily. If email is hosted externally and the existing MX and authentication records are preserved, the website can usually be migrated independently. If email is hosted on the old server, mail migration requires separate planning.

7. What happens if I change nameservers?

DNS authority moves to the DNS service associated with the new nameservers. All required DNS records should exist there before the change.

8. How long does DNS propagation take?

There is no single guaranteed duration. It depends on record TTL values, resolver caches and DNS infrastructure. Planning around TTL and keeping both environments available reduces risk.

9. Should TTL be lowered before migration?

For planned changes to important records, lowering TTL in advance can help resolvers refresh those records sooner during cutover.

10. Can I test the new server before changing DNS?

Yes. Depending on the hosting setup, a staging URL, temporary domain, preview mechanism or local hosts-file mapping can be used.

11. Will SSL automatically migrate?

Not necessarily. The new server must have a valid certificate and HTTPS configuration for the domain.

12. Can WordPress be migrated without downtime?

Usually it can be migrated with very little downtime. Dynamic sites may require a final database and uploads synchronization before cutover.

13. What happens to new orders during migration?

If the database was copied earlier, new transactions created afterward will not automatically appear on the destination unless synchronization or replication is used.

14. Can migration affect SEO?

Yes, if URLs, HTTPS, redirects, robots.txt, canonical settings, status codes or server availability are mishandled. A correctly executed hosting-only migration should preserve SEO signals much better.

15. Should I change hosting and domain registrar simultaneously?

It is generally safer to perform them as separate operations unless there is a specific reason to combine them.

16. Should I change PHP versions during migration?

Only when necessary. Keeping the destination environment compatible with the existing application reduces variables during migration.

17. What if the new website shows a database connection error?

Check database name, username, password, hostname, permissions and whether the database was imported correctly.

18. What if the website shows a 500 Internal Server Error?

Check server/PHP logs, PHP compatibility, .htaccess, PHP extensions, permissions and application configuration.

19. How long should old hosting be retained?

Several days is a reasonable minimum for many ordinary sites. Business-critical systems may justify a longer overlap period based on operational risk.

20. What is the safest overall migration method?

Build and test the new environment in parallel, synchronize the latest data, switch DNS only after validation, keep the old environment operational, monitor production and maintain a tested rollback path.

 

#HostingMigration #WebsiteMigration #WebHosting #HostingTransfer #ServerMigration #WebsiteTransfer #WordPressMigration #DNSMigration #DNSPropagation #DNSTTL #DNSRecords #Nameservers #WebsiteBackup #DatabaseBackup #MySQL #MariaDB #WordPress #SSL #HTTPS #EmailMigration #MXRecords #SPF #DKIM #DMARC #WebsiteSecurity #DataProtection #ZeroDowntime #WebsiteDowntime #MigrationChecklist #MigrationStrategy #HostingGuide #WebsiteManagement #ServerManagement #WebServer #cPanel #SFTP #SSH #Rsync #PHP #DatabaseMigration #WebsiteTesting #WebsiteMonitoring #SEO #TechnicalSEO #CloudHosting #WebsiteSecurityTips #ITSupport #WebDevelopment #SystemAdministrator #HostingTips