Migrate a Website from BigRock

Move the hosting, keep the domain where it is

Moving a website off BigRock is a cPanel-to-cPanel copy: files, databases and mail go to the new account while the old one stays live, then DNS points at the new server. The domain registration can stay at BigRock, because a hosting move and a registrar transfer are two separate jobs.

BigRock sells both registrations and hosting. You can leave the registration untouched and change only where the site is served. That is one nameserver or A-record edit, not a transfer with an authorisation code and a 60-day lock.

• Hosting move: files, databases, mailboxes and DNS. BigRock keeps serving until you cancel.
• Registrar transfer: unlock, authorisation code, and a lock measured from registration or the last transfer.
• Do them in different weeks. Together, one failure makes the other impossible to read.

WebJi® is not BigRock and this is not their support desk. No BigRock phone number, chat line or support address is printed here, because the steps below do not need one.

What moves off BigRock and what does not

A cPanel full backup carries the home directory and the databases. It does not carry the inboxes, so treat the mail copy as a separate task with its own test.

Write the DNS records down before you touch anything. That list is the rollback plan, and it takes two minutes at the start.

Back up files and databases from BigRock cPanel

Log in to the hosting panel for the domain, not the billing area. On a cPanel account open Files, then Backup, and run Full Account Backup. Download the archive before you close the tab, and keep it until the new site has run for a week.

If the tool refuses a large account, take the parts instead: zip public_html in File Manager, export each database from phpMyAdmin, and copy the DNS zone. Over SSH the database dump is one command.

1. In cPanel open Files, then Backup, and choose Full Account Backup. When the archive appears, download it and note its size.
2. Dump each database: mysqldump --single-transaction --routines --triggers -u USER -p DBNAME > DBNAME.sql
3. Download wp-config.php or the equivalent configuration file. It names the database, user and host you have to recreate.
4. Copy every record in the zone: A, CNAME, MX, TXT for SPF and DKIM, and the TTL. Screenshot the page as well.

Do not edit files at BigRock after the archive is taken. Every change after that point has to be repeated on the new server.

Restore the copy on the new cPanel account

Create the domain on the new account first, then restore into it. A cPanel archive that contains a homedir folder unpacks straight into public_html; a bare folder of files has to be moved there by hand.

1. In the new cPanel open MySQL Databases, create the database and a user, and add the user to the database with all privileges.
2. Upload the archive to the account home with File Manager, then Extract. For a full cPanel archive, use the host's restore tool or ask support to restore it.
3. Import the dump in phpMyAdmin, or run mysql -u USER -p DBNAME < DBNAME.sql. The table count should match the old server.
4. Edit wp-config.php with the new DB_NAME, DB_USER, DB_PASSWORD and DB_HOST. The host is rarely localhost on a new account.
5. Set folders to 755 and files to 644: find . -type d -exec chmod 755 {} \; then find . -type f -exec chmod 644 {} \;
6. Confirm .htaccess came across. Without it, permalinks and redirects break while the home page still loads.

You know the restore worked when the table count matches, the configuration file connects, and the site loads from the new server's temporary URL.

Recreate mailboxes and sync old mail over IMAP

Mail is stored on the mail server, not in public_html. A website backup moves the site and leaves every inbox behind, which is the failure people notice a week later.

1. In the new cPanel open Email Accounts and create each address, alias and forwarder that exists at BigRock. Match the spelling exactly.
2. Test the copy in dry mode: imapsync --host1 mail.old --user1 you@domain --password1 OLD --host2 mail.new --user2 you@domain --password2 NEW --automap --dry
3. Run the same command without --dry, then run it a second time. The second pass copies only what arrived during the first.
4. Compare the message count per folder on both sides, then send a test message from an outside address and reply to it.

Change MX only after that test. Keep the old MX value written down, and add the new server to SPF in the same edit so outgoing mail is not filtered.

You know mail moved when each folder shows the same count on both servers and an outside sender reaches the new inbox.

Test the copy before DNS moves

Send one computer to the new server while the domain still resolves to BigRock. Edit the hosts file, or skip the edit and use curl with --resolve for a single request.

• macOS and Linux: add 203.0.113.10 example.com www.example.com to /etc/hosts.
• Windows: the same line goes in C:\Windows\System32\drivers\etc\hosts, opened as administrator.
• No edit: curl -I --resolve example.com:443:203.0.113.10 https://example.com/ returns the new server's headers.

Replace the example IP with the one in the new account's welcome email. Then walk the site: home page, an inner permalink, an image, the stylesheet, the contact form and the admin login.

You know it worked when every check passes over HTTPS with no mixed-content warning. Remove the hosts entry afterwards, or your own browser keeps hiding propagation problems.

Cut DNS over and keep BigRock paid for a week

Lower the TTL on the A record to 300 seconds a day before the switch. A short TTL makes a mistake reversible in minutes instead of a day.

1. Record the current answer: dig +short NS example.com and dig +short A example.com.
2. At BigRock open Domains, then Manage, then Nameservers, and replace the entries with the ones in the WebJi® welcome email. Or change only the A record and leave the rest.
3. Check from two resolvers: dig +short example.com @1.1.1.1 and dig +short example.com @8.8.8.8. Both should return the new IP.
4. If anything fails, put the old nameservers or A value back. The BigRock account is still live, so the rollback is a copy and paste.
5. Cancel BigRock only after a week of normal traffic, and download a final backup before the account closes.

Cached records follow the old TTL, so some visitors still reach BigRock after the change. That window is why the old plan stays paid, and why the TTL drop comes first. The nameserver guide covers the registrar side for other providers.

What the move costs on WebJi and on BigRock

WebJi® charges ₹700 one-time for a domain hosting migration: FTP files plus up to five MySQL databases up to 5 GB, before 18% GST. Shared cPanel hosting starts at ₹300 a month on L-Basic. Free migration is available subject to terms and approval, so confirm the scope by email before work starts.

BigRock's own migration page, read on 29 October 2026, lists ₹5,000 for up to 10 GB with ₹1,000 per extra GB, and a free one-time move only on VPS and dedicated terms. Their shared plans are not covered by that free move.

The cPanel hosting page lists the plans, the migration service page covers the move onto WebJi®, and business email hosting is where mailboxes land if you would rather not run mail on the web account.