Skip to main content
Migrating a production server to the cloud is one of the highest-risk operations your IT team will perform. A disciplined, checklist-driven approach is what separates a smooth overnight cutover from an extended outage that affects your customers and staff. This guide breaks the migration process into three phases — Pre-Flight, Cutover, and Rollback — so every action has a clear owner, sequence, and success criterion before you touch a single production system.
This checklist is designed for migrating existing on-premise or co-located servers to KHCOLO’s cloud infrastructure. If you are provisioning a brand-new environment with no existing data to move, you can skip Phase 1 and start from the Cutover phase.

​
Phase 1 — Pre-Flight Preparation

Complete every item in this phase at least 48 hours before your scheduled cutover window. Rushing pre-flight steps is the leading cause of unplanned migration outages.
1

Audit Your Current Infrastructure

Document every production server: hostname, IP address, operating system, installed services, and open ports. List all application dependencies — databases, shared file stores, external APIs, and SaaS integrations. Record which users and systems connect to each server, and from which IP ranges.
  • Full inventory of all servers and VMs
  • Dependency map (what talks to what)
  • List of public hostnames and DNS records that will need updating
  • List of static IP addresses and firewall rules in use
2

Confirm Bandwidth Capacity

Contact KHCOLO to verify that your new cloud server’s uplink can sustain your peak concurrent call bandwidth. For 3CX deployments, calculate the worst-case bandwidth demand:
  • G.711 codec: ~87 kbps per call (bidirectional)
  • G.729 codec: ~31 kbps per call (bidirectional)
  • Opus (WebRTC): ~50–80 kbps per call
  • Peak concurrent call count confirmed with business stakeholders
  • Bandwidth headroom verified with KHCOLO (recommend 20 % overhead buffer)
  • Confirm cloud server NIC/uplink speed (minimum 1 Gbps recommended)
3

Configure Perimeter Firewall Rules

Harden the new cloud server’s firewall before it carries any live traffic. Apply the principle of least privilege: allow only what is explicitly required.
  • Restrict 3CX SIP and media ports to known carrier IP ranges
  • Allow SSH (port 22) from trusted admin IPs only — not 0.0.0.0/0
  • Allow HTTPS (port 443) for management interfaces
  • Block all other inbound traffic by default
  • Enable logging on rejected connections for post-migration review
KHCOLO can provide a pre-hardened firewall template for 3CX deployments on request. Ask your account engineer during onboarding.
4

Generate a Full Final Backup

Before any data transfer begins, create a complete, transactional snapshot of every production system. This snapshot is your insurance policy — it must be verified and stored independently of the source system.
  • Full VM snapshot or bare-metal backup of all production servers
  • Database dump with consistent transaction state (e.g., mysqldump --single-transaction)
  • 3CX backup exported via the 3CX Management Console
  • Call recordings archived to secondary storage
  • Backup integrity verified by restoring to a test environment (see Backup Strategy)
5

Reduce DNS TTL

Lower your DNS TTL values 24–48 hours before cutover so that DNS changes propagate quickly when you flip the record to your new cloud IP.
DNS TTL changes must be made 24 hours before cutover to take effect across the internet’s resolver cache. If you reduce TTL at the moment of cutover, some users will continue reaching your old server for up to the previous TTL duration (often 3,600 seconds or more). This is one of the most commonly missed pre-flight steps.
  • Identify all A, AAAA, MX, SRV, and CNAME records associated with migrating services
  • Reduce TTL to 300 seconds (5 minutes) on all relevant records
  • Confirm reduced TTL has propagated using dig <hostname> +short or a DNS propagation tool
  • Schedule TTL restoration (3,600 seconds) 24 hours after successful cutover
6

Provision and Validate the New Cloud Server

Set up your new KHCOLO cloud server, install and configure your application stack, and perform end-to-end functional testing before any live traffic is directed to it.
  • Cloud server provisioned with correct OS, CPU, RAM, and storage tier
  • Application stack installed and configured (e.g., 3CX, web server, database)
  • Data synchronised from production to new server (or restored from backup)
  • All services start cleanly after a reboot
  • Internal smoke test completed: make test calls, load test pages, verify database connectivity
  • Monitoring and alerting configured (CPU, RAM, disk, service health checks)

​
Phase 2 — Cutover

Execute the cutover during a low-traffic maintenance window — typically late evening or early morning, Friday to Saturday. Notify all stakeholders in advance.
1

Freeze Changes on Old Server

Put the existing production server into a read-only or maintenance state to prevent data divergence during the cutover window.
  • Maintenance page or redirect enabled on old web services
  • Application write operations paused or queued
  • Final incremental data sync from old server to new server completed
  • Confirm row counts, file checksums, or equivalent data-integrity checks pass
2

Update DNS Records

Point all DNS records to your new cloud server IP address.
  • Update A/AAAA records to new cloud server IP
  • Update MX, SRV records if mail or SIP registration is changing
  • Confirm propagation from multiple geographic vantage points
  • Test application connectivity via the updated hostname (not the IP address)
3

Run Post-Cutover Validation

Verify every critical function works correctly on the new server before declaring the migration complete.
  • Place test phone calls (inbound and outbound) via 3CX
  • Confirm voicemail, IVR, and call recording are functional
  • Verify web applications load correctly under the production hostname
  • Check email delivery (send and receive) if mail services were migrated
  • Review application error logs for new exceptions or warnings
  • Confirm all monitoring alerts are green

​
Phase 3 — Rollback

Prepare your rollback runbook before cutover begins. A rollback plan that is written under pressure during an incident is not a plan — it is a guess.
1

Define Rollback Triggers

Agree with stakeholders in advance on the specific conditions that will trigger an immediate rollback. Document these in your runbook and communicate them to all participants in the cutover call.Example rollback triggers:
  • Post-cutover call failure rate exceeds 5 % after 15 minutes
  • Critical application errors appear in logs with no immediate fix identified
  • Data integrity check fails after DNS flip
  • Migration window exceeds scheduled time by more than 30 minutes
2

Execute Rollback if Required

If a rollback trigger is hit, follow these steps in order:
  • Revert DNS A/AAAA records to old server IP
  • Confirm DNS has propagated and old server is receiving traffic
  • Restart services on old server if they were stopped during freeze
  • Verify application functionality on old server
  • Notify all stakeholders of rollback status
  • Document the incident: what failed, what was observed, what was reverted
3

Post-Migration Review

Whether the migration succeeds or requires a rollback, conduct a structured review within 48 hours.
  • Review all application logs from the cutover window
  • Confirm backup jobs are running successfully on the new server
  • Restore DNS TTL to 3,600 seconds
  • Decommission old server only after 7-day stability observation period
  • Update network diagrams and documentation to reflect new topology
KHCOLO’s managed migration service includes a dedicated engineer assigned to your cutover window. They will monitor your new cloud server in real time and can action rollback steps within minutes if required. Ask your account manager about managed migration packages.