7 Stores. Database at 95% Capacity.
Upgraded to 2.4.8 While Customers Kept Shopping.
Zero Minutes of Downtime.
A European electronics retailer ran 7 Magento websites across 5 countries from a single installation. Their database was at 95% capacity — a ticking clock. Their server was crashing during peak traffic. Missing security patches created compliance risk. They needed an upgrade urgently. The one thing they couldn't afford was downtime — their stores operate 24 hours a day across European time zones.
Seven Stores. Five Countries. One Ticking Time Bomb.
This European electronics retailer had been running their entire multi-market operation — 7 country-specific websites serving Germany, France, Netherlands, Spain, and Poland — from a single Magento 2.4.6-p6 multi-store installation. At peak this installation handled 4,200 concurrent sessions across all 7 stores simultaneously. The architecture was sound. The maintenance had been neglected.
Three critical problems had developed simultaneously over 18 months. First, the database had grown to 95.4% capacity — a combination of unarchived order history, orphaned session data, and an unconfigured log rotation that had been writing to the database since launch. A database at this fill level degrades MySQL query performance exponentially and risks full-store outages when it hits 100%. Second, 4 Magento security patches had been skipped since their last update, creating PCI-DSS compliance exposure that their payment processor had flagged in a recent audit. Third, their checkout success rate had fallen to 84% — a 13% drop from 12 months earlier — caused by Elasticsearch 7 timeouts under load that were silently failing product search during checkout upsell steps.
Why zero downtime was non-negotiable for this specific client
With 7 stores across 5 European time zones, there is no off-peak window where all stores are simultaneously quiet. German and Polish stores peak at different times. A store taken offline for maintenance at 3am CET is still serving active Spanish customers at 2am. Any upgrade strategy requiring a maintenance window affecting all 7 stores simultaneously would result in significant revenue loss and SLA breaches with their enterprise marketplace partners.
The 7 stores and their relative traffic load:
What 3 Days of Audit Found — And Why the Database Was the Most Urgent Fix
Before planning the upgrade execution, we spent 3 days on a full technical audit of the installation. The audit confirmed all 3 known problems and identified 4 additional risks that would have caused post-upgrade failures.
| Issue Found | Severity | Root Cause | Resolution |
|---|---|---|---|
| Database at 95.4% capacity | Critical | 6 years of unarchived logs + orphaned sessions | Cleaned before upgrade |
| Elasticsearch 7 checkout timeouts | Critical | Real-time reindex under load — 84% checkout rate | OpenSearch 2.x migration |
| 4 missing security patches | Critical | PCI-DSS v4.0 non-compliance flagged | Included in 2.4.8-p2 upgrade |
| PHP 8.1 — approaching EOL | High | PHP 8.1 security support ends Dec 2025 | Upgraded to PHP 8.3 |
| 11 extensions — no 2.4.8 release | High | Vendors abandoned extensions on 2.4.6 | 7 replaced · 4 patched |
| Varnish cache TTL misconfigured | High | TTL set to 0 — full-page cache never serving | TTL corrected per store |
| Custom price rules — 3 broken | Medium | 2.4.7 price rule engine change | Rules rebuilt in new format |
| Log files — 48GB on application server | Medium | No log rotation configured since launch | Rotation configured + archived |
The database cleanup was done before the upgrade began — not as part of it. Removing 6 years of accumulated log data, orphaned sessions, and unarchived historical data reduced the database from 95.4% to 41% capacity. This single step reduced average query response time by 68% and immediately reduced peak server load — before the upgrade ran a single command.
How We Upgraded 7 Live Stores Without Taking a Single One Offline
The zero-downtime upgrade used a blue-green deployment architecture — a technique where the upgraded version is built and tested on a parallel infrastructure ("green") while the live production ("blue") continues serving customers. The cutover is a DNS/load balancer switch that takes under 90 seconds and is instantly reversible if needed.
Blue-Green Deployment Architecture
Upgraded Magento 2.4.8-p2 environment built in parallel — customers never touched the upgrade process
(Live production)
(Upgrade build)
The critical moment — the cutover itself — took 84 seconds of load balancer reconfiguration. During those 84 seconds, in-flight requests completed on Blue and new requests began routing to Green. No customer session was interrupted. No order was lost. The Blue environment was kept on standby for 72 hours as an instant rollback option — never needed.
11 Days From Kickoff to Go-Live — Day by Day
Days 1–3: Audit + Database Emergency Cleanup
Full technical audit producing 8-issue risk register. Database cleanup: archived 6 years of order history to cold storage (keeping 24 months hot), purged orphaned sessions, removed 48GB of application logs, configured log rotation. Database dropped from 95.4% to 41% capacity. Query response time improved 68% before the upgrade started — the client noticed the performance change immediately.
🗄️ DB: 95.4% → 41% · Query speed +68% · Done before upgradeDays 4–5: Green Environment Build
Provisioned parallel infrastructure on the same data centre (Amsterdam). Configured identical server specifications to production. Cloned production database and file system to Green. Ran Magento 2.4.8-p2 upgrade on Green — clean execution with pre-resolved conflicts from the audit. Upgraded PHP to 8.3. Migrated from Elasticsearch 7 to OpenSearch 2.x with corrected scheduled reindex configuration.
🖥️ Green environment live · 2.4.8-p2 running · PHP 8.3 activeDays 6–7: Extension Migration and Price Rule Rebuild
Replaced 7 abandoned extensions with actively maintained 2.4.8-compatible alternatives. Patched 4 extensions whose vendors had released partial compatibility updates. Rebuilt 3 custom price rules in the 2.4.7+ format — tested against all 7 store configurations including multi-currency and multi-language edge cases. All 7 stores showing correct pricing on staging.
🔌 11 extension issues resolved · Price rules verified across 7 storesDays 8–9: Performance Optimisation + Load Testing
Corrected Varnish cache TTL (had been set to 0 — full-page cache was never serving). With TTL corrected to 4 hours and OpenSearch replacing Elasticsearch, ran load test simulating 4,200 concurrent sessions across all 7 stores. Green environment handled peak load with 38% lower server CPU than Blue at equivalent traffic. Checkout success rate on staging: 99.1% across 500 test transactions.
📊 4,200 concurrent sessions tested · CPU load -38% · Checkout 99.1%Day 10: Final Delta Sync + Pre-Cutover Checklist
Ran delta sync to pull 7 days of new orders, customers, and product updates from Blue to Green. 87-item pre-cutover checklist: all 7 stores verified on Green (product pages, cart, checkout, payment processing, order confirmation, admin operations, all 5 languages). Scheduled cutover for 3:47am CET — the 15-minute window each week when combined traffic across all 7 stores is at absolute minimum.
📋 87-item checklist · Delta sync complete · Cutover scheduledDay 11: 84-Second Cutover — Zero Downtime
Load balancer reconfiguration at 3:47am CET. In-flight Blue requests completed normally. New requests routed to Green from 3:47:44am. Ran live transaction verification on all 7 stores within 4 minutes of cutover. All payment gateways confirmed. All 7 store languages confirmed. Admin panels on all 7 websites confirmed. Blue environment kept on standby. By 4:15am the client's operations team confirmed their end-of-night sales reports were running normally.
✅ Cutover: 84 seconds · All 7 stores live · Zero rollback requiredBefore and After — Across All 7 Stores
📈 Measured Impact — 30 Days Post Go-Live
What This Case Study Teaches About Multi-Store Zero Downtime Upgrades
Database health is a prerequisite — not an afterthought
Cleaning the database before the upgrade improved performance by 68% before a single upgrade command ran. A database at 95% capacity degrades every operation that depends on it. Treat database health as the first phase of any upgrade, not the last.
Blue-green deployment makes zero downtime possible for any store
Most store owners believe Magento upgrades require downtime. They don't — they require a parallel environment. The additional infrastructure cost for 11 days is a fraction of the revenue that would be lost during a multi-hour maintenance window for a 24-hour multi-country operation.
Varnish misconfiguration is silent and catastrophic
This store's full-page cache had been set to TTL 0 since launch — meaning Varnish was installed but never caching anything. Every page request hit PHP and MySQL from scratch for 6 years. Fixing one configuration value delivered a 42% performance improvement instantly. Check your Varnish TTL.
The checkout success rate is the most important number you should be tracking
This store's checkout rate had fallen from 97% to 84% over 12 months — a 13% drop that was costing them approximately €28,000/month in abandoned transactions. Nobody noticed because nobody was tracking it. Checkout success rate should be on every ecommerce dashboard, checked weekly.