Guides
Three Go-Lives, Not One Big Launch: How We Rebuilt Vitacom in Steps
October 23, 2026 - by Alexandru-Manuel Carabus
The Vitacom rebuild that won at HIVE Germany 2026 had no launch day. It had three, between February and May: secure, simplify, and only then accelerate. What went live in each phase, what we measured before the next, and five rules for your own phased relaunch.
The Vitacom rebuild that won Best Performance Improvement at HIVE Germany 2026 didn't have a launch day. It had three, between February and May 2026, and each one went live and was measured before the next one started.
A big-bang relaunch puts every change on one night: new server, new modules, new frontend. If something breaks, you don't know which change did it, and going back means undoing all of it. Three go-lives meant three smaller nights, each with one kind of change and its own way back.
The order came from the audit
Our technical audit in November 2025 found a store that was slow, but also exposed: 12 security patches missing, three old test copies of the shop open to anyone on the live server, and no two-factor login for the admin. It set the order in one line: secure, simplify, and only then accelerate. And one rule: the Liquid Framework goes only on a clean, secure Magento.
Phase 1, February: secure
The first go-live moved the store to a new server built for Magento: Varnish, then Nginx and PHP-FPM, Redis for cache and sessions, RabbitMQ for the queues and a database tuned for Magento. Magento went from 2.4.6-p1 to 2.4.6-p13, with all 12 missing patches. The test copies closed, TLS 1.0 and FTP went off, and a firewall and two-factor login went on.
Security went first because it can't wait. Among the missing patches was CosmicSting, the hole behind more than 4,000 hacked stores in 2024 by Sansec's count. A faster frontend on an open store is just a faster target.
On launch day, the same admin page loaded twice as fast as on the old server. We sized the new server at 16 cores instead of 64, with headroom on purpose while we learned the store.
Phase 2, March: simplify
In early March, ElasticSuite, with our own brand modules, replaced 32 modules by two vendors: search, filters, merchandising and brand pages. Later that month, Magento moved to 2.4.8. On the way, we also removed a module that emptied stock reservations every 15 minutes.
The database felt it straight away: its CPU load fell to a third on average, and at the busiest moment from 16 cores' worth to 3. A full search reindex, 2 hours 24 minutes at the audit, takes 1 minute 45 seconds today.
Simplifying before accelerating is the step many rebuilds skip. Put a cache and a new frontend over 290+ modules and the slow parts are still there, just hidden until the next page that isn't in the cache.
Phase 3, 19 May: accelerate
On the night of 19 May, the Liquid Framework and Hyvä Checkout went live on the clean store. Business clients who log in get cached pages too, per customer group. After go-live, database CPU, which had sat between 200% and 350% (1 vCPU = 100%), stayed mostly under 50%. Only then did we move the store to 8 cores.
The results are in our post on the server 8 times smaller and the Vitacom case study: server response went from 15,814 ms to 12 ms, on 8 times less hardware.
Planning your own phased relaunch
- Audit first, and write the order down. What puts the store at risk, what slows it down, what only makes it look old. Fix them in that order.
- Security first. Patches, access and backups can't wait for the redesign.
- One kind of change per go-live. Server, modules, frontend: if each goes live on its own night, you know which one caused what, and each has its own way back.
- Measure before the next phase. Pick three numbers and write them down before and after: server response, database CPU and real-user LCP.
- Keep go-lives away from campaigns. Plan around Black Friday and Christmas: nothing goes live in campaign week.
On Magento and Hyvä
In the Liquid Framework, every change gets its own preview, and deploys roll back on their own when something fails. On Vitacom, 12 health checks run every 30 seconds. That turns a phased relaunch into a series of ordinary deploys, not a separate project for each phase.
Planning a relaunch, or stuck in one? Book a free strategy call. We'll go through your store with you and put the work in an order you can ship in steps.
Get the next article in your inbox
One email a month with new articles, speed fixes and the Magento security patches worth applying.