Zero-Downtime Migration of a 1.5TB E-Commerce Platform
For almost a decade, the client’s e-commerce platform has been running on premise and has been built up with the common issues that come with a long-lived monolith. It ran on PHP 5.6, well past its security support window, with product images and invoices stored on local disk instead of shared storage. User sessions were tied to whatever server handled the request, so a shift in traffic could log a customer out mid-checkout. The MySQL database was too large (1.5TB) and had a very high write load, so moving with a maintenance window wasn’t an option. This ruled out a standard lift and shift, and with hundreds of orders coming in each hour, downtime wasn’t something the client could afford.
Bobcares built a side-by-side environment rather than planning a single cutover. Application state moved out of the legacy server first, the database was replicated live into Azure, and traffic shifted over gradually instead of all at once.
Business Challenge
The client needed a high-traffic e-commerce platform moved off aging on-premises infrastructure and into Azure without downtime, since every interruption during migration meant orders that would not get placed. That constraint shaped the sequencing of the entire migration, from how state was externalized to how traffic was finally cut over.
Technology Used
Blueprint
The legacy PHP 5.6 application was containerized with Docker and run on Azure App Service, while file storage and session state moved to Blob Storage and Redis so both environments could share the same backing services during the transition. A live MySQL replica kept the Azure database synchronized with the on-premises master while Azure Front Door managed the gradual shift of traffic between the two.
Key Outcomes
- Zero minutes of downtime during the migration
- 35% faster checkout performance
- Multi-zone deployment for resilience against hardware failures
- Staging slots in place for safer future deployments
Customer Profile
The Challenges
- The application ran on PHP 5.6, which was well past its security support window
- Product images and invoices were stored on local disk instead of shared storage
- User sessions were tied to local folders, so a shift in traffic could log customers out mid-session
- The MySQL database had grown to 1.5TB under constant write load, making a maintenance-window migration unworkable
- The existing architecture ruled out a standard lift-and-shift approach
- Any downtime during migration would translate directly into lost revenue
Why Bobcares?
- Externalized files and sessions let both environments read and write the same data during the transition
- Live database replication kept the Azure database current without requiring a freeze on the source
- Routing traffic through Azure Front Door in phases caught problems before they reached every customer
- Containerizing PHP 5.6 preserved the application’s existing dependencies without a rewrite
What We Delivered
- Containerized the legacy PHP 5.6 application in Docker to run on Azure App Service
- Moved file assets, including product images and invoices, to Azure Blob Storage, with both environments writing to it during the transition
- Moved user sessions to Azure Cache for Redis, giving the application consistent session handling across servers
- Set up Azure Database for MySQL as a read replica of the on-premises master
- Kept the replica synchronized down to the transaction level using binlog replication over a secure VPN
- Introduced Azure Front Door to control and reroute traffic during the cutover
- Rolled traffic over in phases, starting with a warm-up period, moving through canary release and scaling tests, and finishing with full cutover
- Promoted the Azure database to master and decommissioned the on-premises server once cutover completed
- Applied Azure Web Application Firewall for protection against SQL injection, XSS, and related exploits
- Tracked performance and errors throughout the migration using Azure Monitor and Application Insights
The Results
Downtime
- Before: An interruption of any length risked lost orders on a platform handling hundreds of transactions an hour.
- After: The migration itself ran with zero minutes of downtime from start to finish.
Performance
- Before: Checkout previously ran on legacy on-premises infrastructure with no documented performance baseline.
- After: Checkout got 35% faster after the move to Azure.
Reliability
- Before: The application had been running in a single environment with nothing to fall back on if hardware failed.
- After: Multi-zone deployment now covers that gap.
Future Deployments
- Before: Changes to the old environment carried no safe rollback path if something went wrong.
- After: Staging slots now give the client a place to test changes before they reach production.
The Business Impact
- Migration completed without any customer-facing downtime or lost orders
- Faster checkout reduces friction at the point most likely to cause cart abandonment
- Multi-zone deployment reduces the platform’s exposure to a single hardware failure
- Staging slots give the client a lower-risk path for testing future changes before they reach production
- Session and file data are no longer tied to a single server, which removes a recurring source of customer-facing session issues
Conclusion
Externalizing sessions and file storage before touching the database is what made a zero-downtime cutover possible. That sequencing, moving state first, replicating the database second, and shifting traffic last, avoided the need for a maintenance window entirely.
With the legacy server decommissioned, the client now runs on infrastructure that supports multi-zone resilience and staged rollouts for future changes, without the session lock-in or local storage constraints that limited the original platform.
