Overcoming tech debt for your CMS migration

Technology debt is the cost incurred by the quick fixes and workarounds made to speed up development now that add a complexity tax to development work down the line. It’s an expected growing pain of business, but if steps aren’t taken to minimize tech debt, it can quickly snowball into major costs to team productivity, maintenance needs, and the performance and scale of your applications.

Tech debt is a challenge that increases as digital business gets more complex. In a 2018 survey by the payment platform Stripe, developers reported spending 33% of their time on technical debt. In a 2020 survey by the research firm McKinsey Digital, CIOs reported that tech debt amounted to 20 to 40% of the value of their entire technology estate. A 2023 survey by the service provider SoftwareOne found that 72% of organizations are behind on digital transformation due to tech debt.

This article will look at common sources of tech debt to watch out for when migrating to a new content management system (CMS), ways to measure and monitor the impact of debt, and proactive measures teams can take to minimize debt during migration.

#Introduction to technical debt in CMS migration

Proactively managing debt as part of your migration strategy leads to a smoother transition and lowers the total cost of ownership (TCO) of the new content solution. Here are four common sources of tech debt to watch out for when planning your CMS migration.

1. Lack of communication between teams

Untangling the existing web of content isn’t always easy. It takes coordinating with multiple departments to understand what assets, data, and workflows are used across the business. A planned migration without this full content picture often leads to one-off fixes down the line and misses out on opportunities to simplify and standardize processes globally.

2. Carrying over old debt

Once a business decides that there are strong enough reasons to replatform to a new CMS, it’s important to make sure that migration isn’t just a lift-and-shift of problems from one platform to the next. Too many teams waste time and resources moving over outdated assets, duplicate data, and unused features. Or recreating complex workflows that require ongoing maintenance of outdated tools instead of using the new CMS capabilities to improve working methods.

3. Not taking advantage of new technology

There have been big advances in business software in the past few years, but due to time pressure and skills gaps, some companies end up moving to these modern tools without fully capitalizing on what they have to offer. Such as continuing to use monolithic approaches to data and integrations and missing out on the flexible scaling of the Cloud, still thinking in a page-based mindset when using a headless CMS so that assets aren’t set up for reuse and personalization, or creating a publishing process that still requires developer intervention instead of making sure business users can manage the full content lifecycle through a friendly user interface (UI).

4. Poor change management

Changes to content management can impact multiple teams with a range of technical literacy. If training and employee adoption are treated as an afterthought, it can be a painful transition process or, even worse. All migration work is done just for people to default back to old working methods. Additionally, if the initial migration team doesn’t properly document knowledge, it can be hard to ramp up new hires and risks losing critical information if someone leaves.

#How to measure tech debt

Attaching financial and business value to tech debt is key to being able to prioritize and allocate funds to managing it. While it’s hard to get an exact measurement of debt’s impact, here are a few ways to evaluate and communicate the cost of current debt and the value of improvements made.

Code quality

Tools like SonarQube and Teamscale can be used to scan code for issues like unused code, undocumented code, duplication, test coverage, and security vulnerabilities. Comparing these metrics month over month can help to highlight the “interest rate” of existing tech debt.

For a deeper look at measuring tech debt via code quality, check out this study that saw a 90% smaller tech debt growth rate when moving from monolith to microservices.

Team productivity

Attaching a dollar amount to productivity can be useful when justifying the need for a different solution and, once the migration is done, to prove the value of the new platform.

One way to get an estimate of costs saved due to productivity is to multiply the number of people working on a specific task, the average salary of those people, the percent of their time spent on that task before migration, the percent reduction in time spent on the task post-migration, and by 50% to estimate that half of the time saved will be captured as costs saved.

Annual loss expectancy

Annual Loss Expectancy (ALE) is a straightforward calculation to show the financial impact of known security, compliance, and performance risks that tech debt contributes to. ALE is the Single Loss Expectancy (SLE) of an event multiplied by the Annualized Rate of Occurrence (ARO) of that event.

Proxy measures

Depending on where tech debt has caused the most frustration, monitoring improvements to impacted systems can be a good way to represent progress on debt.

These can be trackable metrics in ticketing tools like Jira, such as number of bugs reported, mean time to resolution (MTTR), full cycle time for projects, and rate of new features released. As well as site performance metrics like conversion rates, bounce rates, and page speed. Even big-picture stats around developer retention, number of missed deadlines, amount of steps in the content workflow, and time to onboard new hires can be useful to illustrate the impact of tech debt on the business.

#How to manage technical debt for your CMS migration project

Here are 5 ways to minimize tech debt in your CMS migration project and improve performance, scalability, and lower maintenance costs down the line.

Set up an internal migrations team

Changes to the CMS will impact multiple teams, and it’s useful to have a group of representatives from different departments aligned on key milestones and goals.

This group can help in the planning process by giving insight into how content is currently used, identifying challenges, and pledging resources for migration tasks. They can also ensure a smooth transition by helping to create global standards for content governance, knowledge documentation, and training colleagues in their department on the new ways of working.

Conduct a content audit

Take a look at existing assets and data to find the ROT (redundant, obsolete, trivial) that doesn’t need to be moved over.

For the remaining data, map out where it lives, who owns it, the content types that use it, and the relationship between data sets. Having a good understanding of how data supports different processes is particularly important when moving from a monolithic to headless CMS, as legacy data models may not map 1:1 to a headless approach and will need to be tweaked when migrated.

Consolidate and simplify workflows

Evaluate the content workflows happening across the business to see where capabilities overlap, what outdated tools are causing frustrations, and how processes can be simplified with the new CMS.

The German food and beverage company, Dr. Oetker, uses a headless CMS to manage the digital experience of 40 countries from one content platform. The backend infrastructure is shared globally while each market still has the freedom to create unique frontend experiences, with granular permission set up to ensure that content editors only see the products, content, and data that are relevant to their region. This setup makes it easier to keep the brand consistent, streamline business processes, and roll out global updates at a fast pace.

Design a composable content strategy

Getting the most out of a headless CMS requires breaking out of a page-based mindset and designing content models for omnichannel businesses.

A composable content strategy defines a set of reusable content models, like a “blog post model” or “call to action model,” that can be reused and displayed in many different ways across many different channels. This modular approach allows developers to quickly build solutions for current use cases, with the flexibility to add and adjust individual models to meet future needs. It also lets business users mix and match content components to create unique experiences without needing the help of a developer.

For a look at how a composable model works in practice, have a look at this example of content components for a news website.

Federate your content sources

The ever-increasing scope of digital experience means that content will likely rely on data from multiple applications and external sources. To avoid future tech debt, these sources need to be brought together in a way that minimizes maintenance-heavy integrations and resource-intensive batch processings.

Hygraph Content Federation simplifies data management by making all data available through a single GraphQL API. Data continues to live in the original source, with Hygraph grabbing the most up-to-date information from each system as it’s requested. Giving companies a way to efficiently manage how data flows between frontend customer interactions and backend systems.

The biotechnology publisher, BioCentury, uses Content Federation to combine data from multiple remote sources to deliver academic articles, news, analysis, research collections, visualizations of real-time data, and many other content types to their subscribers. Enabling an 80% faster content publishing time compared to their old system.

#What’s next

Whether you’re planning on a big bang CMS migration or taking a gradual approach, Hygraph offers tools and support for a smooth transition:

• Content API & Management SDK for efficient development.
• Auto-generated GraphQL mutations to help you unify the data of all your remote sources.
• Low-code Schema Builder that lets teams structure composable content in minutes.
• Friendly User Interface (UI) to provide a rich editing experience for a headless content strategy.

For more information on successfully switching your content platform, have a look at our eBook: The True Cost of CMS Migration.