---
title: Hosting Migration
description: Moving files, databases, mail, and DNS to a new host with a plan that keeps downtime and errors low.
canonical: https://penasihathosting.com/en/hosting-wiki/hosting-migration
type: wiki
locale: en
updated: 2026-07-15
author: Willya Randika
---

# Hosting Migration

## Overview

- **Summary:** Moving files, databases, mail, and DNS to a new host with a plan that keeps downtime and errors low.
- **Author:** Willya Randika ([profile](/penulis/willya-randika))

## Article

**Hosting migration** means moving a website — files, database, mail, and DNS — from one server or provider to another with as little downtime as possible. A clean migration feels like a planned house move; a rushed one often ends in wrong DNS, broken mail, SSL errors, or forms that no longer send.

Migration is not only “FTP the files.” Sequence, [TTL](/en/hosting-wiki/dns-ttl), [backups](/en/hosting-wiki/backup-hosting), tests on [staging](/en/hosting-wiki/staging), and post-cutover verification decide whether visitors feel pain.

## A Simple Analogy

It is like relocating an office: you copy the archives (database), place the furniture (files), change the street signs (DNS), and make sure power and keys (PHP, SSL) fit before staff arrive Monday morning. Forgetting the office phone lines (MX email) is as bad as forgetting the reception desk.

## Typical Checklist

1. Inventory domains, mail, cron, SSL, and third-party integrations  
2. Take a full backup at the source  
3. Prepare the destination account; match [PHP](/en/hosting-wiki/php) versions when possible  
4. Copy files into the correct [document root](/en/hosting-wiki/document-root)  
5. Import the database and adjust connection settings  
6. Test via hosts file or staging before public cutover  
7. Lower TTL, then change [DNS](/en/hosting-wiki/dns-domain-name-system) or [nameservers](/en/hosting-wiki/nameserver)  
8. Enable [HTTPS](/en/hosting-wiki/http-https); check forms, login, cron, and mail ([SPF](/en/hosting-wiki/spf)/[DKIM](/en/hosting-wiki/dkim))  
9. Monitor errors for 24–48 hours before decommissioning the source  

## What to Watch For

- Mail often breaks because MX/TXT records were not moved  
- Old URLs embedded in content need careful search-replace  
- Avoid Friday-evening cutovers without on-call coverage  
- Keep source hosting access until you are confident  
- Document rollback: when DNS can be pointed back  

## FAQ

<Accordion>
  <AccordionItem title="How much downtime is reasonable?">
    With planning, DNS cutover can be minutes to a couple of hours. Very large sites or complex mail can take longer.
  </AccordionItem>
  <AccordionItem title="Are migration plugins enough?">
    They often help small and mid-size sites, but still verify mail, cron, SSL, and payment integrations manually.
  </AccordionItem>
  <AccordionItem title="Change nameservers or only A records?">
    It depends who manages DNS. What matters is editing the zone that is actually authoritative.
  </AccordionItem>
  <AccordionItem title="When is it safe to cancel old hosting?">
    After DNS is stable, mail works, and no dependencies remain — usually days later, not the first hour.
  </AccordionItem>
</Accordion>