Get the best of both worlds
Gazza Azhari explains how and why to retain existing components while moving to a Sitecore website
Why would someone want to keep an older tool when moving to a modern DXP platform?
So, you want to move to using Sitecore to make it easier to maintain a large, high-quality website, but you’ve already invested in bespoke applications or features your team and clients are accustomed to?
This is the situation the Victorian Department of Transport and Planning was in when they asked us to re-purpose some of the widely used components that were built on their old PTV website to ensure compatibility and styles adjustment, as they moved to a new Sitecore website, Transport Victoria.
The old website contained a Journey Planner tool many Victorian users of public transport use every day. The client wanted to keep this tool exactly as it was to avoid the cost of replicating it in a new site, with all the potential attendant costs, delays and issues associated with writing and testing new code, along with the increased cognitive load for users.
These are the steps we took to merge the old with the new
In order to maintain the older tool (component) and include it within the new website, we:
containerised the component to run independently within a standalone NextJS environment
integrated the component into the new site via a custom Sitecore rendering component, allowing it to maintain its original behaviour and design while fitting seamlessly into the new Sitecore architecture and environment.
implemented a bridging layer for data and styling, ensuring the component could access required services and assets while inheriting updated styles to match the new site branding where appropriate.
What are future steps for the client?
In future, the client will likely develop the Journey Planner tool within Sitecore, so it’ll be integrated and will benefit from reusable React components that enable rapid updates and enhancements.
By approaching this as a separate step, the client has time to thoroughly plan and test the replacement tool and to communicate any changes to the people who will use it.
What’s componentisation?
Componentisation, also known as component-based development, refers to the practice of breaking down the user interface into smaller, reusable components that encapsulate both logic and interface. This approach allows developers to build more efficient, scalable, and maintainable applications.
This was our approach when initially building the original PTV site, making use of frameworks such as React that promote clean separation of components.
This made it far simpler to extract frequently-used features from the old PTV website into standalone React components. These components were then integrated into the new Sitecore XM Cloud using the native JavaScript component wrapper with Next.JS in our case, which connects to Sitecore XM Cloud and enables the use of its features. By applying concepts of atomic design, we structured components from small, reusable building blocks (atoms) to more complex UI elements (organisms), ensuring faster development due its reusability and better maintainability across the application.
Why use React components?
React components save time and money, while retaining high quality output, because they enable a composable editing experience rather than building from scratch.
Sitecore XM Cloud’s native support for NextJS, ReactJS, and other popular JavaScript frameworks allow for seamless integration of modern front-end frameworks with enterprise content management, enabling us to reuse existing components, accelerate development time, and deliver consistent experiences without compromising performance or functionality.
Why is a staged release sometimes preferred?
A staged release is a gradual approach to test and deploy new features, where changes are introduced in phases to minimise risk and ensure a smooth transition before full release. This method allows teams to test and refine specific features in smaller increments. In the aforementioned project, the staged release strategy was applied when integrating the existing Journey Planner tool to the Sitecore XM Cloud while keeping core functionalities intact.
The advantages of taking a staged approach – making a move to Sitecore, and enjoying all its attendant improvements – while retaining and seamlessly linking to existing features like this Journey Planner tool, reduces development effort, time, costs and risks, and leaves the user experience as it is.
Managing risks during a staged release
The phased rollout allowed us to test new features and make adjustments without disrupting the user experience. Risks were managed by testing each stage in controlled environments, ensuring that the updates to the user interface and the backend system were thoroughly validated before full deployment. This, in turn, reduces cost and development time.
How do you decide whether to re-use existing components or simply recreate them in a new platform?
When deciding whether to re-use existing components or recreate them in a new platform, it is important to weigh both business and technical factors. The decision often depends on specific project goals, resource constraints, and long-term maintainability considerations.
Below are some factors to consider when evaluating whether to re-use existing components or recreate them:
Technical compatibility – evaluate whether existing components are compatible with the new platform. Consider the needs for refactoring, performance impact, maintainability and the complexity of integration
Reusing legacy components may present challenges, and in some cases, starting fresh may offer a more flexibility and robust solution
Time and cost – reusing existing components can save time and lower initial costs, while recreating them may require higher upfront investment but provide greater flexibility and scalability in the long run
Risk – reduce the risk of business disruption during the transition, ensuring key features are maintained while new functionalities are gradually added
