The constraints we walked into
The client is a Fortune 500 retailer with significant North American and European online operations. The engagement brief, when we started, looked unforgiving on every axis. Replatform from a heavily customized monolith to a composable architecture. Four vendor partners involved: a CMS provider, a commerce platform, a search and personalization vendor, and a CDN/edge provider. Three geographic regions running in different store models. A brand refresh — new visual identity, new content tone — landing in parallel. And a non-negotiable cutover deadline four weeks before the brand's peak commercial season.
Most engagements with this constraint shape do not succeed. The standard failure mode is that the technical migration eats the entire engagement's attention, vendor coordination becomes ad-hoc, the brand refresh gets compressed into a 6-week sprint at the end, and the peak-season deadline slips by a month or two. The brand survives — peak season happens on the old platform, the new platform launches in Q1 of the following year — but the engagement is read as a partial success at best.
This engagement succeeded against all four constraints. The reason it succeeded is worth being specific about.
The structural decision in month one
In the first month, our team made one structural decision that ended up shaping the entire engagement. We treated vendor coordination as the primary work and technology migration as the secondary work.
This sounds backward. The contract was for technical delivery. The CFO was paying us to migrate the platform. What we saw in the first month was that the four vendor partners had inconsistent timelines, conflicting assumptions about scope, and no shared definition of what "ready for production" meant. If we ran the engagement as a technical migration with vendor management as a side task, those four inconsistencies would compound across 14 months and the peak-season deadline would be at risk.
So we restructured. One full-time program lead from our team owned vendor coordination as their primary job. Weekly vendor sync meetings became the engagement's spine. Every technical decision was preceded by a vendor-coordination decision — which vendor owns this seam, which vendor depends on this output, what is the agreed timeline. The technical migration ran as a parallel workstream beneath the coordination layer.
This decision was uncomfortable for the client team initially. They had expected the engagement to feel like a build project. It felt instead like a program-management project with engineering inside it. Six weeks in, the client team understood why. The vendor partners — who had previously been responsible to nobody in particular — were now responsible to a shared schedule with explicit dependencies. The technical work started moving faster because the coordination work was no longer the bottleneck.
How the brand refresh ran in parallel
A brand refresh during a replatform is normally a recipe for one of two failures. Either the refresh delays the platform (the new design system is not ready when the platform needs to launch), or the platform delays the refresh (the new design system gets compromised to fit what the platform can render).
We avoided both by making one specific structural choice: the design system was treated as a contract between the brand team and the platform team, with explicit handoff milestones. Month three: design tokens locked. Month five: component-library frozen for the first migration wave. Month seven: full visual-identity sign-off. The platform team built against the contract, not against the moving target of an in-progress refresh.
The brand team disliked this initially. Brand work normally evolves up until launch. The contract forced them to lock decisions earlier than they were comfortable with. The trade was that the platform launched on time with the new brand intact, rather than launching late with a compromised brand or on time with the old brand. The brand team's assessment at the end of the engagement was that the discipline was uncomfortable but produced a better outcome than the standard pattern.
How the regional rollout was sequenced
Three regions, three different store models, three different teams in three time zones. The default pattern for multi-region rollouts is either all-at-once (high risk) or one-region-fully-then-next (slow, with the second region being delayed by lessons learned in the first).
We used a third pattern: parallel readiness with staggered cutover. All three regions ran technical readiness in parallel — the engineering work happened simultaneously across all three. Cutover was staggered by two weeks per region, with the smallest region first.
This pattern has two advantages. The parallel engineering compresses the timeline meaningfully — roughly 30% faster than sequential rollouts. The staggered cutover absorbs the operational risk of an unexpected issue in region one without delaying regions two and three, because regions two and three are already technically ready when region one's issues surface.
Region one cutover happened in week 50. Region two in week 52. Region three in week 54. The peak-season commercial deadline was week 60. The four-week buffer between region-three cutover and peak season was used for stabilization and last-mile polish.
What worked and what we would do differently
Worked: the vendor coordination spine, the brand-as-contract structure, the parallel readiness pattern. All three were unconventional and all three were the reason the engagement succeeded against the constraint set.
Worked less well: the search and personalization vendor was added to the engagement four months in, after the client decided their existing search tooling was not going to meet the new platform's requirements. Adding a vendor mid-engagement is always painful, and it was painful here. The lesson — which we now apply to every replatform engagement — is that vendor selection has to be complete before month one ends, even if it forces uncomfortable decisions earlier than the client team would prefer.
Would do differently: we underestimated the content migration. The composable architecture required all content to be migrated into the new CMS in a different structure than the monolith had used, and the content authoring team had not been given enough lead time. The migration happened on schedule but the content team was working evenings for two months. The lesson is that content migration has to be treated as a parallel workstream from week one, not as a downstream consequence of the technical migration.
Result: the platform launched four weeks before peak season, the brand refresh shipped intact, all three regions were live, and the peak commercial season ran on the new platform with revenue performance ahead of the prior year. The engagement transitioned into a managed services arrangement for the following 18 months, which we still operate.