How Interspire migrations actually work — what the 48-72 hour timeline covers
About a quarter of our managed Interspire engagements start as migrations from another hosting provider rather than from-scratch installs. The 48-72 hour migration timeline is real and we hit it consistently, but the activities that fit inside that window are worth understanding so operators can plan accordingly. The walkthrough below is what actually happens during a typical Interspire migration engagement.
Pre-migration discovery (24-48 hours before migration starts)
Before we touch the legacy system, we audit it: Interspire version (determines upgrade-then-migrate vs migrate-as-is path), PHP version on source server (determines compatibility with destination stack), MySQL version and database size (determines dump strategy), filesystem size (determines transfer time), customizations to track during migration (custom themes, modified controllers, third-party addons installed, integration touchpoints), DNS configuration (subscription form domains, tracking domains, sender domains), IP addresses currently in use and warmup state, FBL registrations to transfer or re-register. The output is a written migration plan that goes to you for approval before we proceed. Most discovery completes within 24-48 hours; complex installs with extensive customizations may take longer.
Day 1: New environment provisioning + first data copy
We provision the destination server (AlmaLinux 9, PHP 8.3, MySQL 8.0, Nginx 1.24, PowerMTA 6.0) using our standard managed-Interspire stack. Initial database dump from the source server, restored on destination. Filesystem rsync from source to destination. Interspire admin UI brought up on destination using temporary subdomain. We run a smoke test: log in, verify list counts match, send a single test campaign to a personal email address. This first-day work happens with the source system still actively operating; no traffic has moved yet. Source system continues sending campaigns normally.
Day 2: Customization validation + integration testing
If the source had customizations (modified controllers, custom themes, custom integrations with external systems), Day 2 is when we validate they work on the destination. Some customizations need updating for newer Interspire versions; some need updating for newer PHP versions; some integration credentials need rotation. We run these in staging mode on the destination — not yet receiving traffic — to confirm everything works before promoting to production. About 60% of migrations have at least one customization that needs adjustment during Day 2; the remaining 40% are clean and Day 2 is mostly verification.
Day 2-3: Final data sync + DNS cutover
Once the destination is validated as working correctly, we do a final database dump-and-restore (incremental from Day 1 baseline, capturing any campaign sends that happened during the migration window). DNS cutover happens at a coordinated time: we update A records, MX records (for bounce processing), CNAME records (for tracking domains), and TXT records (DKIM, SPF, DMARC). DNS propagation takes 30-60 minutes typically; during propagation, traffic gradually shifts from source to destination. We monitor metrics on both systems during this window to catch any unexpected issues.
Day 3: Post-cutover validation + source decommissioning
After DNS fully propagates, we validate that all traffic is hitting the destination correctly: subscription forms working, tracking pixels firing, click-through redirects functioning, bounce processing flowing, FBL signals reaching the destination's bounce mailbox. Once we confirm 24 hours of clean operation on the destination, we decommission the source system: shut down services, take final backup, archive credentials, terminate the source server (or hand it back to you to decommission depending on engagement terms). The full timeline from "go" decision to "destination operational + source decommissioned" is typically 48-72 hours; longer for installs with extensive customizations or complex DNS topologies.
What can extend migration beyond 72 hours
Three factors regularly push migrations past the 72-hour baseline. First: extensive customizations requiring porting — heavily customized themes, modified controllers, third-party addons that need re-installing or updating. Second: large datasets requiring extended transfer windows — installations with 5M+ subscribers or hundreds of GB of campaign history take longer to dump, transfer, and restore than smaller installs. Third: legacy version migrations requiring intermediate upgrades — migrating from Interspire 6.1.x directly to 8.7.x is not a single-step operation; we typically do 6.1.x → 7.0.0 → 8.5.0 → 8.7.x in staged upgrades over 5-7 days. We flag these scenarios during discovery so timeline expectations are realistic upfront.