New year, old systems. Your modern DXP looks sleek, but it keeps bumping into that box of legacy you shoved in the closet.
That box is not going away on its own, and that is fine. The goal is not to erase history. The goal is to make it pay rent.
Right now feeds are full of ChatGPT demos, teams are rushing GA4 setups before the summer switch, and companies are trimming cloud bills and headcount. Inside that mix, many teams are trying to push a modern DXP while older parts still carry real traffic and revenue. The question is not if you have legacy. The question is how you use it without letting it drive the whole car.
When I say modern DXP I mean the stack that powers content, journeys, commerce, and service across web, app, email, and whatever new screen pops up next. Think headless CMS, search, personalization, consent, analytics, and a customer data platform plus a heap of APIs. A lot of folks are moving to a more composable style, picking best parts instead of one giant suite. It is tempting to draw a clean picture on a slide and call it done. Then someone says the old catalog service still owns pricing in five regions and cannot move until quarter four. Welcome back to reality.
Perspective first: legacy is a feature request
Legacy is not just old code. It is policy, contracts, data shape, and people. It runs money things and compliance things. Treating it like a bug to squash usually burns months and mood. Better to treat it like a stakeholder with a feature request: what job does it still do well, what job should move, and what job must retire with a cake and a photo.
Here is a simple frame I use with teams:
- Keep: parts that are stable, paid for, and still best at their job. Example: a tax engine with rare updates but perfect accuracy.
- Wrap: parts that must stay for now but need a better face. Put an API in front, add caching, clean the data at the edge.
- Strangle: parts that hold you back. Route new features around them and starve them of fresh paths until only a core is left to move.
Be honest about why something stays. If the reason is comfort, say it out loud. If the reason is risk on a core flow, that is a real reason. Put time on it. Time, money, and morale are the three dials. You rarely get to turn all three up.
Decisions that shape a modern DXP with old parts inside
Most teams are picking between two broad moves. One is a full suite with many features from one vendor. The other is a set of focused tools you wire together. Both can work. With a suite you accept the shape of that world and you get speed and shared support. With a composed stack you get more choice and you own the wiring. The right answer depends on skills, budget, and how often you change direction.
When you mix modern tools with older systems, a few choices have outsized impact:
- Where does truth live: pick the place that owns the record for things people care about. Orders, prices, profiles, consent. Do not split truth across tools without a plan. If your old ERP still owns price, let it own price and cache it at the edge. If your headless CMS owns product copy, let it own product copy and keep it clean.
- How does data move: use events for things people need to react to, like order placed or profile updated. Use batch for bulky jobs at calm times, like promotions sync. Use APIs for quick reads and writes in a request path. Do not push everything through one pipe.
- What runs at the edge: put fast decisions close to the user. Feature flags, geo based content, basic offers. Leave heavy decisions to the core. This keeps old systems from sitting in the hot path.
For many teams the first battle is identity. Single sign on sounds easy until three legacy apps all want to be the boss. Decide the primary identity provider and move dependents to trust it. If you cannot migrate all at once, start with new users and keep a bridge for old sessions. Clean identity unlocks everything else from personalization to consent to analytics.
Next is content. A headless CMS brings a nice way to reuse blocks, manage locales, and ship fast. The trap is cloning an old page tree one to one. Model content around purpose not around the old screen. Write a schema that matches how your team writes and how your channels consume. The more your model mirrors intent, the less you fight it later.
Watch analytics this quarter. Universal Analytics is inching toward sunset and GA4 is not a drop in swap. Many teams are running dual tags right now. That is a good move. Do not wait to map events and consent flows. Your legacy tag soup will not map cleanly. Define the event names you actually need and teach product folks to think in those terms.
Practical tradeoffs you can explain to your boss
People do not buy architecture. They buy outcomes. So frame choices in user and money terms. These are the tradeoffs I see most often and how I phrase them.
- Release cadence: keeping an old core while shipping a new front lets you move faster on the surface. You will ship more experiments. You will also carry a tax in the shape of adaptors and test complexity. Budget time for those adaptors like you budget time for features.
- Performance: routing every request to an old backend kills speed. Cache at the edge, pre render where you can, and fetch late only when the answer is personal. Measure time to first byte and time to interactive. Numbers beat feelings in meetings.
- Team shape: a composed stack needs folks who enjoy wiring and documentation. A suite needs folks who learn every corner of that product and push vendors for features. Tossing people at the wrong shape burns them out. Hire for the shape you pick.
- Vendor fit: a suite can lower finger pointing. When something breaks in a composed stack you are the routing layer and the support layer. That is fine if you accept it and set up on call rules and observability. If you do not want that, pay for a suite and hold them to strong service levels.
- Cost curve: older systems often have sunk cost. New tools bring clear monthly bills that feel bad at first. Balance that feeling with the cost of not shipping and the cost of people doing manual work around the gaps.
There are also nuts and bolts that cut across all stacks. Put attention here and your life gets calmer:
- Event naming and contracts: pick a clear set of events and keep them stable. Document payloads. Changes must be versioned. This makes your DXP feel like a product and not a tangle.
- Error budgets and alerts: define what good means for content delivery, search, identity, and checkout. Track it. Alert on it. Legacy problems often show as slow browns not loud reds. Catch browns early.
- Consent and privacy: do not bolt this on. Wire consent decisions into analytics and personalization at the start. If a user says no, nothing should sneak around the side. You will thank yourself when audits arrive.
- Search and discovery: legacy content is often a junk drawer. Invest in tags, synonyms, and quality signals. People cannot convert on things they cannot find.
- Feature flags and kill switches: every risky connection to an older service should have a way to turn off fast. Flags are not just for experiments. They are for survival.
One more note on teams. With layoffs in the news and budgets under review, keep scope hungry but delivery sane. Pick one or two high value threads and finish them. For many groups that is identity cleanup and GA4 readiness. For others it is a content model refactor so authors can stop pasting the same block into five places. Small wins buy air cover for the bigger moves.
Patterns that help legacy and modern tools live together
These patterns are boring in a good way. They are the duct tape you reach for again and again:
- API facade: put a friendly API in front of the old system. Hide weird shapes and odd errors. Add caching and retries. Your front ends and partners get a clean contract while you slowly clean the core.
- Event fan out: publish one event for a business moment and let subscribers do their jobs. Order placed can feed email, analytics, loyalty, and a warehouse feed without each tool talking to each other in a knot.
- Read from cache write to source: for slow reads and strict writes, keep a warm cache for reads and write through to the owner. Works well for catalogs and profiles. Watch staleness and set sane TTLs.
- Strangler fig: put the new path in front and route only the parts the old system still needs to handle. Over time you route less to the old path. This is patient work but it lets you ship real features while cutting the cord.
- Dual run: when moving a critical thing like pricing or promotions, run both paths for a while and compare results. Show the diff to business folks. Confidence beats guesswork.
People also ask about migration big bang or step by step. Step by step wins most of the time. Big bangs sound clean until you list all the unknowns. Step by step lets you move by capability. You can switch pricing reads this month, then move search, then move promotions. Each move is boring on purpose.
On tooling, the MACH crowd keeps pushing good ideas about packaged business capabilities, APIs, cloud native things, and headless. Take the spirit if not the sticker. The point is to keep parts small, clear, and replaceable. That sets you up to swap a vendor without a year of pain. Replaceable beats perfect.
Reflective close: ship now, clean as you go
We started with a box of legacy in the closet. It is not a monster. It is part of your story. With clear owners for truth, a calm plan for data flow, and a few humble patterns, that box can feed your modern DXP instead of tripping it. Pick the next thin slice you can ship in four weeks. Make it visible. Measure it. Then pick the next one. Progress beats purity and your users will feel it long before anyone agrees on the perfect diagram.