Sooner or later, every business finds itself at a crossroads where its tech stack isn’t performing as it once was, and it’s time to retire it and start fresh or upgrade to a new system. The upgrade of your tech stack is known as brownfield software development.
What you do with your CMS matters significantly during a brownfield project due to its role in building and maintaining an engaging digital presence. In this blog, we’ll explain more about brownfield migration and the challenges and opportunities that await.
#What is a brownfield software development
Brownfield software development refers to the practice of working on and enhancing existing software systems, applications, or projects. When organizations take this approach, they simply migrate their current systems to another, typically newer and more advanced version—for example, upgrading to version 3.0 of a software application or moving from a legacy CMS to a modern headless CMS.
Brownfield development involves modifying existing software to address issues, add new features, or adapt to changing requirements. Businesses that use the brownfield software development approach typically have years of data and processes stored, such as in proprietary systems, and are unable to simply stop using everything.
#Greenfield vs. brownfield software development
Greenfield software development refers to an approach where everything is created from scratch. Companies reengineer their entire infrastructure from the ground up without worrying about being constrained by their existing codebase.
Instead, the greenfield approach offers a clean slate where engineering teams can work without limitations. For example, a startup that has spun out of a larger enterprise or a company preparing to launch a brand new product or service in another region might opt for a greenfield approach.
There are, of course, several differences between the greenfield and brownfield approaches. We will list the differences below.
| Brownfield development | Greenfield development | |
|---|---|---|
| Existing codebase | Works with an existing codebase or software system | Starts from scratch with no pre-existing code or system limitations |
| Constraints | Can leave developers constrained by legacy code, architecture, and technical debt | No constraints from legacy systems or code, offering more flexibility |
| Technology stack | May need to work with existing technology stack or infrastructure | Free to choose the most suitable and modern technology stack |
| Use cases | Common in scenarios where updates or migrations are required | Often chosen for entirely new projects or when existing systems are outdated |
#Different approaches to brownfield projects
Brownfield emerged because enterprises can’t simply start from scratch when building a new tech stack. They have existing content and data assets. In one fell swoop, a complete overhaul of the existing site or application would be too risky if the existing site or application was shut down and rebuilt from scratch.
Roughly ten years ago, downtime was estimated to cost about $5,600 per minute, which has likely increased tremendously today, given the increase in digital endeavors since then. As such, companies today can’t afford the downtime that occurs if they were just to shut down their existing system and start from scratch.
When the brownfield approach gets applied to migration, two options are usually available: Big Bang or strangler.
In a big bang migration, all data assets are migrated from the old system to the new system in one instance.
In a stranger migration approach, systems and data assets are split into microservices and migrated piece by piece, like several mini-migrations happening.
#Migrating the brownfield project CMS
As part of your brownfield project migration, your CMS will likely need to be migrated as well. While some challenges will need to be overcome, there are also potential opportunities that can be realized by taking the brownfield approach.
Challenge: Extended time to completion
he time for the migration to be completed could take weeks or months, depending on the project size. In order to not interrupt your current content workflows, it might take an extended period to plan and coordinate the whole project until completion.
Opportunity: Leverage your CMS vendor's expertise
Depending on the new CMS you’re migrating to, you can get help from your vendor. Platforms built on MACH architecture, for example, make connecting with other solutions in your tech stack easier so that you don’t need to rebuild every integration from scratch.
Also, you can start building blocks in your new CMS like Hygraph. With features like Content Federation, you can start by fetching content and data from external sources so that your frontend looks new, and you can replace the backend later piece by piece.
Replatforming from a monolithic stack takes work. With Hygraph, you can be confident that your project will succeed no matter the approach you choose: a big bang approach or a gradual replatforming; the technology can support you either way.
Hygraph’s Management SDK, API, and UI make creating and managing your schema and content easier during replatforming. Using the Hygraph schema and Content API, you can create any content types and fields you wish, and they will be available immediately. Use as many or as few of the system content types and system fields as you need. You can either normalize your schema now or use String and JSON fields later to represent as much of your data without any modification.
Challenge: Elevated cost to maintain both systems
The other concern that comes when migrating your brownfield project CMS is that you will need to maintain both systems: your legacy system and your modern system. This can lead to extra cost.
Additionally, depending on the size of the team performing the migration and whether or not you got external help, it could be an additional strain on your resources; both the engineering team handling the migration and the marketing team working on SEO and content migration or creating content for websites on both systems.
Opportunity: Consider future TCO and ROI
Managing both systems can be challenging, but you should remember the total cost of ownership now and later, as well as the return on investment of a newer modern system. Changing from a monolithic to a microservice-based system saves money since you don't need to maintain the whole system while the new one is being built. Instead, you exchange one microservice and shut down the old one. Migrating from a legacy CMS to a headless CMS also ensures a faster time to market for launching new websites, products, and services.
Additionally, a headless CMS can provide better scalability to meet increased traffic demands and expand to new regions and other challenges that could arise.
Challenge: System knowledge gap
When companies shift from legacy or traditional systems, there will be a knowledge gap between people implementing and using the new system. Overcoming this knowledge gap can prove tricky, depending on the state of the new system. For example, many headless CMS tools are built with developers in mind, which can be challenging for non-technical personnel to manage.
Opportunity: Embrace an user-friendly CMS with easy onboarding
Choosing a SaaS CMS means that the system is maintained and updated by the vendor, which means companies don't need to worry about implementation as external experts will always be on hand to guide them.
In addition, while some CMS solutions are hard to work with for newcomers, opting for a platform with easy onboarding processes and an intuitive UI can make things easier for your team.
Hygraph offers tooling that enables content teams to create, reuse, and distribute content to multiple channels without relying on developers. Teams can collaborate effectively, build workflows and permissions, and do anything else they need to create engaging content for customers. Hygraph provides an improved developer experience for engineering teams and offers a native GraphQL API to achieve high performance.
It took us about 1 week to set up our Hygraph-powered ad server. In contrast, in a previous job our team needed 2 months to implement an ad server based on a traditional CMS.
Challenge: Content compatibility The new system you migrate to will likely have a new data structure and metadata management system. Brands should ensure that the new CMS has features like flexible content modeling, components, and so on to ensure consistency, content structure, and content governance.
Opportunity: Omnichannel content delivery
A headless CMS offers the opportunity for omnichannel content delivery. With the flexibility to publish content to any desired channel as well as adapt to different requirements, migrating to a CMS with these features can be undoubtedly worth the effort.
When Dr. Oetker needed to upgrade all the websites, apps, and portals under its brands, they migrated to Hygraph due to its MACH-compatible approach, ability to handle multiple brands, and overall future-proof capabilities. They needed to unify data silos and enhance the end-user experience.
With Hygraph’s unique ability to handle granular permissions across multiple brands & projects, as well as high-performance APIs and an intuitive UI, the Dr.Oetker team was able to modernize their tech stack fully.
Going for a sustainable, state-of-the-art headless content platform was very important to us. With Hygraph, we are able to centralize the tech stack allowing us to easily launch into new markets just by replicating the environments and migrating the content..
Challenge: Navigating performance risk
When undertaking a brownfield project, website or app performance risks can arise, especially when dealing with the integration of a CMS. One primary challenge is the potential for increased latency due to the complexity of the migration process. Migrating content, databases, and templates from the old system to the new one can lead to slower load times and unoptimized content, frustrating users and potentially causing them to abandon the platform.
Additionally, compatibility issues between the old and new systems can result in unpredictable behavior, leading to performance bottlenecks and inconsistencies that negatively impact the user experience.
Opportunity: Embrace better performance with Hygraph
Leveraging a modern, versatile CMS like Hygraph can significantly mitigate these performance risks. Hygraph’s architecture allows for efficient content migration and structuring, reducing latency and ensuring a seamless transition. Its modular components enable developers to fine-tune the performance of the CMS, optimizing content delivery and rendering.
Moreover, Hygraph’s focus on scalability and flexibility empowers organizations to adapt to growing demands, ensuring that website or app performance remains robust even as traffic increases. By embracing the right CMS and implementing performance-focused strategies, organizations can turn the challenges of brownfield project migration into an opportunity for improved website and app performance.
#Wrapping up
Brownfield project migration can sometimes seem more challenging than starting from scratch with a greenfield approach. However, given that starting from scratch isn’t always possible for enterprises today, knowing how to overcome the challenges and seize the opportunities that a modern CMS can bring is just as important.
Learn everything you need to know about migrating to a modern CMS by reading our guide: The True Cost of CMS Migration.
Blog Author