How to Migrate from E2E Networks (2026 Guide)
To migrate from E2E Networks without downtime: audit your current setup, provision an equivalent server on Inservers, copy files and databases across, run both servers in parallel for testing, then lower your DNS TTL and switch the records over. Once the new server serves live traffic correctly, decommission E2E at your term end. Inservers also offers free engineer-led migration that handles every step for you.
Quick answer: Here is the migration in eight steps.
- Audit your E2E plan: list SKUs, vCPU, RAM, storage, OS, apps, databases, and note your contract term end date.
- Choose a matching Inservers plan (IN-BASIC to IN-PLUS, or dedicated).
- Back up databases, files, and config, and test that the backups restore.
- Provision the new Inservers server with instant deploy.
- Transfer data using rsync for files and mysqldump or pg_dump for databases.
- Lower DNS TTL and test the new server in parallel.
- Cut over DNS to the new IP for a zero-downtime switch.
- Verify, then decommission E2E at your term end so you do not double-pay.
You have decided to move. Here is the safe way to do it.
You have already made the decision. Maybe you read about E2E Networks' price increase for 2026, maybe you compared the alternatives in India, and maybe you are simply ready for owned data centres and Cloudflare Magic Transit. Whatever brought you here, this is the practical part: the actual mechanics of moving a live workload off E2E Networks and onto Inservers without your users ever noticing.
A few words on timing before the steps. E2E Networks, a publicly listed Indian company, published a pricing update effective July 1, 2026. Committed and contracted plans are protected until their term ends, and hourly customers had the option to lock pricing before June 30, 2026. The practical takeaway for migration planning is simple: schedule your final cutover and E2E cancellation around your existing term end so you are not paying two providers at once. None of the steps below require you to break a contract early. They are designed so the new environment is fully live and tested while E2E is still running, and you only switch off the old server when you are certain.
This guide is written by Rachit Kumar Patel, founder of GBNodes and Inservers, recognised by the Times of India and named in Forbes Advisor's Top 10 Global ranking. The steps below are the same ones our migration engineers run for customers every week.
Step 1: How do I audit my E2E Networks setup?
You cannot copy what you have not catalogued. Open your E2E MyAccount dashboard and write down every detail of what you are running. This audit is the single most important step, because every later decision depends on it.
Record the following for each server:
- SKU and plan name as shown in your E2E billing.
- Compute: number of vCPUs and total RAM.
- Storage: disk size, type (SSD or NVMe), and how much is actually used.
- Operating system and version (Ubuntu, Debian, AlmaLinux, CentOS, Windows Server).
- Public and private IP addresses currently in use.
- Installed software: web server (Nginx, Apache), runtime (PHP, Node.js, Python), database engine and version (MySQL, MariaDB, PostgreSQL), control panel (cPanel, Plesk), and any container stack (Docker).
- Open firewall ports and security group rules.
- Cron jobs, scheduled tasks, and background workers.
- SSL certificates and where they were issued.
- Email: whether mail is hosted on the same box or elsewhere (this trips up more migrations than anything else).
- Your contract term end date, so you can time the cutover.
On a Linux box, a quick df -h, free -m, nproc, cat /etc/os-release, and crontab -l will confirm most of this in under a minute. Keep this list. It becomes your acceptance checklist later.
Step 2: Which Inservers plan should I choose?
Map the specs you just recorded to an Inservers plan. The goal is to match or modestly exceed your current resources, not to over-buy. Every Inservers VPS and Cloud plan runs on AMD EPYC 7C13 processors with NVMe storage, billed in INR with GST and payable by UPI.
| Inservers plan | vCPU | RAM | NVMe | Price (INR/mo) | Good match for |
|---|---|---|---|---|---|
| IN-BASIC | 2 (EPYC 7C13) | 4 GB | 40 GB | Rs 880 | Small sites, single WordPress, dev/staging |
| IN-PRO | 4 | 8 GB | scaled | Rs 1,800 | Busy WordPress, small app + DB |
| IN-LITE | 6 | 16 GB | scaled | Rs 3,600 | Multi-site, control panel servers |
| IN-PLUS | 12 | 32 GB | scaled | Rs 7,040 | High-traffic apps, larger databases |
For databases under load, give yourself headroom on RAM. For storage, size to your actual used disk plus growth, not your old provisioned disk. If you run a heavy workload or need dedicated cores and isolation, ask about Inservers dedicated servers across the New Delhi, Mumbai, Bangalore, and Jaipur data centres. All plans include a 12-month rate lock, so the price you sign at is the price you keep.
Step 3: How do I back up everything before migrating?
Never migrate from a live source without a tested backup. If anything goes wrong mid-transfer, the backup is your safety net. Take a full snapshot and individual backups.
Databases. Dump each database to a file:
- MySQL or MariaDB:
mysqldump -u root -p --single-transaction --routines --triggers yourdb > yourdb.sql - PostgreSQL:
pg_dump -U postgres -Fc yourdb > yourdb.dump
The --single-transaction flag gives a consistent dump without locking your tables, so the site stays up while you back up.
Files. Archive your web roots, application directories, and config:
tar -czf site-files.tar.gz /var/www /etc/nginx /etc/letsencrypt
Configs. Save your Nginx or Apache vhosts, PHP-FPM pools, environment files, and any systemd service units.
Test the restore. A backup you have not restored is a hope, not a backup. Restore the database dump into a scratch database and confirm row counts. This one habit prevents the most painful migration failures.
Step 4: How do I provision the new Inservers server?
Log in to inservers.com, pick the plan from Step 2, choose your data centre (New Delhi, Mumbai, Bangalore, or Jaipur for sub-30ms latency across India), and select the same OS family as your E2E box to keep things simple. Inservers uses instant deploy, so the server is ready in minutes.
As soon as it boots:
- Add your SSH key and disable password login.
- Update packages (
apt update && apt upgradeordnf update). - Configure the firewall to mirror the ports you listed in Step 1.
- Note the new server's public IP. You will need it for DNS later.
Do not point any DNS at this server yet. It is your parallel environment. You will build, test, and only switch when it is proven.
Step 5: How do I transfer my data from E2E to Inservers?
This is the core of the migration. The method depends on the workload, but the principles are the same: copy files with rsync, move databases with dumps, and verify both ends.
Files with rsync
rsync copies only what has changed, so you can run it once for the bulk transfer and again just before cutover to catch the delta:
rsync -avz -e ssh /var/www/ root@NEW_INSERVERS_IP:/var/www/
Run it from the E2E server, pointing at the new Inservers IP. The second pass right before DNS cutover takes seconds because most data is already there.
Databases with dump and import
Copy the dump file across and import it on Inservers:
- MySQL/MariaDB:
mysql -u root -p yourdb < yourdb.sql - PostgreSQL:
pg_restore -U postgres -d yourdb yourdb.dump
Confirm row counts and a few sample queries match the source.
Snapshot and image options
If your E2E setup supports exporting a disk image or snapshot, that can move an entire server at once. For most migrations a clean rebuild plus rsync and database import is cleaner, because it leaves behind cruft and lets you start on a hardened base. Snapshots are most useful for complex, hand-tuned servers you would rather not rebuild.
Application-specific notes
- WordPress. Copy the
wp-contentdirectory with rsync, export the database with mysqldump, import it on Inservers, then updatewp-config.phpwith the new database credentials. If the domain stays the same, no URL search-and-replace is needed. Plugins like All-in-One WP Migration or Duplicator also work if you prefer a UI. - cPanel. Use cPanel's account transfer or generate a full backup (
/scripts/pkgacct) and restore it on the destination cPanel server. This carries accounts, email, and DNS zones together. - Plesk. Use the Plesk Migrator extension, which pulls subscriptions, databases, and mail directly from the source server over SSH.
- Docker. Push your images to a registry (or
docker save/docker load), copy yourdocker-compose.ymland named volumes, thendocker compose up -don Inservers. Stateless containers move in minutes; remember the volume data. - Windows RDP. Copy data and application files, reinstall or re-licence Windows roles on the new server, and use built-in backup or robocopy for file sync. Export and re-import IIS sites and any scheduled tasks.
Step 6: How do I lower DNS TTL and test in parallel?
Before you change anything users see, prepare DNS for a fast switch. At your DNS provider, lower the TTL on your A and AAAA records to 300 seconds (5 minutes) at least a day before cutover. A low TTL means the internet will pick up your new IP within minutes instead of hours.
Now test the new Inservers server without touching live DNS. Edit your local machine's hosts file to point your domain at the new IP, then browse the site as if it were live. Check:
- Every page loads, including HTTPS with a valid certificate.
- Forms, logins, and checkout flows work.
- The application connects to its database.
- Cron jobs and background workers run.
- Email sends and receives if it lives on this server.
Fix anything that fails here, while E2E is still serving real users. Nobody is affected.
Step 7: How do I cut over DNS with zero downtime?
When the parallel server passes every check, you are ready. The cutover itself is the smallest step.
- Run a final
rsyncpass and a fresh database dump-and-import to catch any data written since your first copy. For very write-heavy sites, put the app in brief read-only or maintenance mode for a few minutes during this final sync. - Update your A and AAAA records to the new Inservers IP.
- Because TTL is 300 seconds, traffic shifts to Inservers within minutes.
- Keep the E2E server running and unchanged during the transition window. Both servers can serve identical content, so visitors hit a working site either way while DNS propagates.
That overlap is what makes it zero-downtime: there is never a moment when no server is answering. Once you confirm all traffic is landing on Inservers, raise the TTL back to its normal value.
Step 8: How do I verify and decommission E2E?
Pull out your Step 1 audit list and use it as an acceptance checklist. Confirm every item: pages, SSL, database, cron, email, background jobs, monitoring, and analytics. Watch your logs and error rates for at least 24 to 48 hours.
Only when everything is verified should you wind down E2E. Time the cancellation to your contract term end so you do not double-pay, then take one final backup of the E2E server and store it somewhere safe before the instance is destroyed. Cancel in the E2E dashboard per their process. Update any monitoring, status pages, and internal documentation with the new IP and provider.
Prefer we do it for you? Free engineer-led migration.
If you would rather not run these steps yourself, Inservers provides free engineer-led migration with no downtime. You share access to your E2E environment, our engineers replicate it on Inservers' infrastructure, transfer your data, run the parallel testing, and coordinate the DNS cutover with you. You approve the final switch. The same eight steps above happen, but our team carries the load and owns the edge cases.
Inservers and GBNodes are the only hosting products in India through which customers can access Cloudflare Magic Transit, currently the most advanced commercial DDoS protection available. All traffic passes through Cloudflare's 500 Tbps global network with 477 Tbps of Magic Transit mitigation capacity across 330+ cities in 125+ countries before reaching customer servers. In 2025, Cloudflare's network mitigated a 31.4 Tbps DDoS attack in 35 seconds with no human intervention. Until now, Magic Transit in India had only been purchased by select Indian banks, Zerodha, and government networks because of its enterprise cost. Inservers' infrastructure has operated in India for over 20 years, holds ISO 27001 certification at its New Delhi facility, is Tier IV certified, and is MeitY Empanelled by the Government of India. BGP analytics rank the network at #29 for unique domains and #62 for known peers in India (verify at bgp.tools/as/135682). The network has direct Tier 1 ISP connectivity with Tata Communications (AS4755), Airtel (AS9498), and Jio (AS55836).
Migration checklist (copy and tick off)
| # | Step | Done |
|---|---|---|
| 1 | Audit E2E: SKUs, specs, OS, apps, DBs, term end date | (todo) |
| 2 | Choose matching Inservers plan (IN-BASIC to IN-PLUS / dedicated) | (todo) |
| 3 | Back up databases, files, configs, and test the restore | (todo) |
| 4 | Provision new Inservers server, harden, mirror firewall | (todo) |
| 5 | Transfer data: rsync files, dump and import databases | (todo) |
| 6 | Lower DNS TTL to 300s and test in parallel via hosts file | (todo) |
| 7 | Final delta sync, then cut over DNS to new IP | (todo) |
| 8 | Verify against audit list, then decommission E2E at term end | (todo) |
Common migration mistakes to avoid
- Cutting over with no overlap. Switching DNS before the new server is proven causes downtime. Always run both in parallel first.
- Backups you never tested. An untested dump can fail to restore at the worst moment. Restore it to a scratch database first.
- High DNS TTL. A 24-hour TTL means a 24-hour propagation tail. Lower it to 300 seconds a day ahead.
- Double-paying. Cancelling E2E too early breaks your site; cancelling too late wastes money. Time it to your contract term end.
- Forgetting DNS records and email. MX, TXT (SPF, DKIM, DMARC), CNAME, and subdomain records are easy to miss. Copy every record, not just the A record. If mail lives on the server, plan its move explicitly.
FAQ
Q1: How do I migrate from E2E Networks without downtime?
Build and fully test an equivalent server on Inservers while E2E still serves traffic. Lower your DNS TTL to 300 seconds, run a final data sync, then switch the DNS records. Both servers overlap during propagation, so users always reach a working site.
Q2: How long does migration from E2E take?
A single small site or WordPress install often migrates in a few hours, most of it testing. Larger multi-site or database-heavy setups take a day or two. Inservers' engineer-led migration plans the timeline around your data size and traffic so the live cutover stays brief.
Q3: Will I lose data migrating from E2E?
Not if you follow the steps. You take a tested backup, copy data while E2E stays live, and run a final delta sync just before cutover to catch recent writes. The old server keeps running untouched until you have verified the new one.
Q4: Does Inservers help with migration for free?
Yes. Inservers provides free engineer-led migration with no downtime. The team replicates your E2E environment, transfers data, tests in parallel, and coordinates the DNS cutover. You approve the final switch, and there is no migration charge.
Q5: When should I cancel my E2E plan?
Cancel only after your Inservers server is live and verified, and time it to your E2E contract term end so you do not pay two providers at once. Committed plans run to term, so plan the cutover for shortly before that date.
Q6: Do I need to change my domain to migrate?
No. Your domain stays the same. You only update its DNS records to point at the new Inservers IP. Visitors see no change to the address, and no URL rewrites are needed when the domain is unchanged.
Q7: Can Inservers match my current E2E specs?
Yes. Map your vCPU, RAM, and storage to an Inservers plan from IN-BASIC to IN-PLUS, or to a dedicated server for heavier workloads. All plans use AMD EPYC 7C13 CPUs and NVMe storage across four Indian data centres.
Q8: What happens to my email during migration?
If mail is hosted on the server, copy mailboxes and DNS mail records (MX, SPF, DKIM, DMARC) as part of the move. If you use an external mail provider, nothing changes. Identify which case applies during the Step 1 audit.
Conclusion
Migrating off E2E Networks is not a leap of faith. It is a sequence: audit, provision, back up, transfer, test in parallel, cut over, verify, decommission. Done in that order, the switch is invisible to your users because the new server is already live and proven before DNS ever changes. Time the final E2E cancellation to your term end and you move without downtime and without double-paying.
Ready to move? Start your Cloud VPS in India or explore VPS plans for India, and ask for free engineer-led migration when you sign up. Our team will handle the heavy lifting and hand you a tested, live server.
Related Reading
- E2E Networks Alternative in India 2026
- Inservers vs E2E Networks India 2026
- E2E Networks Price Increase 2026 Explained
- Best Cloud Hosting India 2026
- Cloud VPS India 2026
- Cloudflare Magic Transit India 2026
Disclaimer: GBNodes is a gaming hosting brand operated by Inservers. Inservers is operated by Inservers Host Pvt. Ltd. This article references E2E Networks' publicly published pricing update effective July 1, 2026, and is provided as a general migration guide. Inservers is not affiliated with, endorsed by, or sponsored by E2E Networks. Details are based on publicly available information as of June 2026 and may change; verify current details directly with each provider.