Panel migrations get a bad reputation because people do them the risky way: convert in place, switch everything at once, and find out on Monday which mailbox stopped working. Done in the right order, a move from cPanel to AstraCloud Panel is boring, and boring is the goal.
This is the plan we use, whether we are doing it for you or you are doing it yourself.
The rule that makes it safe
Never convert a live server in place. Build the new environment alongside the old one, get one site fully working on it, verify it before any DNS changes, then switch. The old server stays untouched and functional the whole time, so your rollback is "change the DNS back" rather than "restore from backup and pray".
What actually has to move
| Component | How it moves | Watch out for |
|---|---|---|
| Website files | Archive and transfer, or rsync | Hidden files, correct ownership after extraction |
| Databases | Dump and import per database | Character set and collation mismatches |
| Database users | Recreate with the same names | Application config files hard-code the user and password |
| Recreate mailboxes, then sync messages over IMAP | Mail is the part people forget until it is broken | |
| DNS zone | Recreate records before switching nameservers | Any record you miss disappears the moment you switch |
| SSL | Reissue on the new server | Reissue before the switch, not after |
| Cron jobs | Recreate by hand | Paths change between servers |
Step by step
1. Inventory first
List every domain and subdomain, every database and its user, every mailbox, every cron job, every custom DNS record - especially MX, SPF, DKIM and any verification TXT records. A migration goes wrong in exactly the places that were not on the list.
2. Build the new environment
Create the account on the new panel with the same domains and subdomains, the same PHP version per site, and the same database names and users. Matching the names means application configuration files keep working untouched.
3. Move files and databases
Copy the files, import the database dumps, fix ownership. For a large site, do a first copy while the old site is live, then a second incremental sync right before the switch - that way the final sync moves minutes of changes rather than gigabytes.
4. Recreate mail, then sync it
Create the mailboxes on the new server with the same addresses, then use an IMAP-to-IMAP sync to copy the messages across. Do this before the DNS switch so mail is already waiting when MX moves. Set up SPF, DKIM and DMARC for the domain on the new server at the same time.
5. Test with the domain still pointing at the old server
This is the step that makes the whole thing safe. Add an entry to your computer hosts file mapping the domain to the new server IP address. Your browser now sees the new server while the rest of the world still sees the old one. Click through the site properly: forms, logins, checkout, image uploads, the admin area.
6. Lower the DNS TTL a day ahead
Drop the TTL on the records you are changing to 300 seconds, at least 24 hours before the cutover. Do it too late and the old value is still cached at the old TTL, which is often several hours or a day.
7. Issue SSL on the new server
Before the switch, not after, so there is no window where visitors see a certificate warning. AstraCloud Panel issues and renews Lets Encrypt certificates automatically once the domain resolves - which is why some setups need the certificate reissued immediately after the DNS change instead. Plan which of the two applies to you.
8. Switch, then watch
Change the DNS or nameservers. Watch the new server error logs for 48 hours. Keep the old account intact for at least a week - it costs one more month of hosting and buys you a rollback.
What usually breaks
- File permissions after extraction. Files owned by the wrong user produce blank pages and 403s.
- Hard-coded paths. Old absolute paths in configuration files and cron jobs.
- Database collation. Importing into a different default collation garbles non-English text - and this matters for Nepali content.
- Missing DNS records. The verification TXT record nobody remembers, until a service stops working a week later.
- Mail sent from the site. A new server IP has no sending reputation. Warm it up, and get SPF, DKIM and DMARC right on day one.
What is different once you are on AstraPanel
The everyday things map across almost one to one: file manager, databases with phpMyAdmin, mailboxes, DNS editor, cron, SSL, backups. What is new is what sits alongside them - Node.js, Python, Django, Go, Java, .NET, Rust, Deno, Bun and Elixir applications, Docker containers, PostgreSQL and MongoDB, Git import with push-to-deploy, and backups you can restore one component at a time instead of all or nothing.
The full comparison, including what cPanel still does better, is on the cPanel alternative page.
Questions
Will my website go down during the migration?
Not if you follow the order above. The old server keeps serving until DNS moves, and DNS moves only after the new server is tested and working.
How long does a migration take?
A single small site is an afternoon, most of it waiting for transfers. A server with dozens of accounts is a project done in batches over a week or two - never in one night.
Can I import a cPanel backup directly?
Treat that as a convenience, not a plan. Moving files, databases, mail and DNS as separate verified steps takes longer but fails visibly instead of silently.
Do you do the migration for me?
Yes - free for normal sites when you move to our hosting. Send us the details through the contact form and we will scope it.