Uniform blog/Your next platform upgrade doesn't need to be a replatform

Your next platform upgrade doesn't need to be a replatform

TL;DR

James Hardie's case demonstrates how an orchestration layer can extend existing technology instead of forcing a disruptive replatform every three to five years. By connecting fragmented data and systems through composable architecture, the team added personalization and streamlined integrations while preserving the tools users already knew. The key takeaway: Invest upfront in data restructuring and reusable connections to make future upgrades faster, more flexible, and less dependent on full-platform migrations.
The replatform cycle is treated as a fact of digital life. Every three to five years, the content platform ages out, the capabilities the business seeks arrive bundled with a rough migration, and marketing teams lose a year waiting as engineering rebuilds the functionality that already worked. The industry has sold this cycle as the cost of staying current for so long that most organizations budget for it like clockwork.
The team at James Hardie stopped paying it.
"We don't have to replatform every three to five years because we need this new functionality, and the old functionality is no longer working," said Sophia Zlatin, manager of marketing technology at James Hardie, speaking in a Uniform webinar on composable architecture. Zlatin owns the martech function for a global building products manufacturer running multiple sites across several geographic markets.

What the company did instead of a rebuild

James Hardie carried the conditions that normally force a replatform. Data lived in disconnected systems across departments, and years of accumulated decisions had shaped it around internal needs rather than the customer-facing web. Zlatin named the problem plainly: many data sources across systems, legacy data outside the web team's control, and "many years of decisions in different departments without having the web customer experience in mind when those decisions are made."
The conventional response is a new platform. James Hardie chose another route and added an orchestration layer over the systems already in place, connecting the disparate sources without overhauling the underlying architecture. Uniform's no-code integrations let the digital team restructure data for online audiences without routing each connection through custom engineering work.
What arrived was capability, without the strain of migration. The team enabled dynamic personalization based on visitor location, improved how digital assets were managed, and cut the volume of custom API development that new integrations previously demanded. Changes that ultimately didn’t require trading out the systems the company was already invest in and trained for.

Being honest about the hard part 

Zlatin was direct about what the approach cost, and this honesty matters more than the outcome.
The initial build was not faster. Composability required an upfront investment of time and planning that a straightforward rebuild would not have demanded, and the first version of the site took as long as it would have taken otherwise. The savings were realized in the projects that followed.
The higher cost sat in the data. Zlatin advises allocating 80% of project time to restructuring back-end data, which is a substantial share of any program arriving with fragmented data and a number most vendors leave out of the pitch. 
What James Hardie changed was choosing to do the work once instead of repeating this effort each time a platform aged out.

Why the architecture matters

In a conventional stack, capability is bound to the platform that delivers it. Personalization belongs to the DXP, asset handling belongs to the asset system, and the connections between them are custom code written for one configuration. Adding capability means either extending the custom code or replacing the platform underneath it, which is how the three-to-five-year cycle establishes itself. The rebuild arrives on schedule because the architecture was built to produce it, and better planning does not change that.
An orchestration layer breaks the binding. Capability lives above the systems rather than inside any one of them, so adding a new feature becomes an addition instead of a migration. Zlatin described the working experience in terms of assembly: "you detach one and attach the other, and it really helps you to not be locked into other platforms." 
Development after the initial build became, in her words, "easier, smoother, more replicable" because expansion no longer required tearing something down to make room. The second project ran faster than the first for no reason related to the team getting better at the tooling.
For the marketing organization, new functionality will now arrive when the business requires it. Engineering will no longer be forced to absorb a rebuild every few years to deliver capability that was never about the repository
The CMS James Hardie ran is still running. What the company can do with it is no longer restricted by its limitations.
Schedule time with an advisor now to learn more about how composable architecture can eliminate forced migration cycles and keep your technology investments productive for years beyond the conventional replacement window.

FAQs

No. Capabilities such as personalization, faster publishing, and connected commerce or asset data can come from a layer that assembles and delivers the experience above the content repository. Adding this layer over the existing CMS delivers the capability without a migration, and the content platform continues as a repository.