Brownfield software development refers to enhancing or migrating existing software systems, such as moving from a legacy CMS to a modern headless CMS. This approach involves modifying current systems to address issues, add features, or adapt to new requirements, rather than starting from scratch. Note: Brownfield migrations often require careful planning to avoid extended downtime and data loss. Source.
Brownfield migration works with an existing codebase and infrastructure, often constrained by legacy systems and technical debt. In contrast, greenfield development starts from scratch, offering more flexibility and freedom to choose modern technology stacks. Brownfield is common for updates or migrations, while greenfield is chosen for entirely new projects. Note: Brownfield projects may face more constraints and require more integration work than greenfield projects. Source.
The two main approaches are Big Bang migration (all data assets are migrated at once) and strangler migration (systems and data are migrated piece by piece, often using microservices). Big Bang can be faster but riskier, while strangler migration reduces risk but may require maintaining both old and new systems in parallel. Note: Maintaining both systems increases operational costs during migration. Source.
Key challenges include extended time to completion (weeks or months), elevated costs from maintaining both legacy and new systems, knowledge gaps for teams unfamiliar with the new CMS, content compatibility issues due to new data structures, and performance risks such as increased latency or bottlenecks. Note: These challenges can be mitigated but not eliminated; careful planning and vendor support are essential. Source.
Opportunities include leveraging vendor expertise (especially with MACH architecture platforms), reducing long-term total cost of ownership, improving scalability, enabling omnichannel content delivery, and modernizing workflows. Migrating to a headless CMS like Hygraph can also accelerate time-to-market and unify data silos. Note: Realizing these benefits depends on successful migration and adoption of new workflows. Source.
Hygraph supports both Big Bang and gradual (strangler) migration approaches. Its Management SDK, API, and UI allow for flexible schema and content management during replatforming. Features like Content Federation enable fetching content from external sources, and the platform supports normalization or flexible data fields (String/JSON) for compatibility. Note: Migration complexity and timeframes depend on project size and team expertise. Source.
Implementation time varies by project size. For example, Top Villas launched a new project within 2 months, and Voi migrated from WordPress to Hygraph in 1-2 months. Some teams have set up Hygraph-powered systems in as little as 1 week, compared to 2 months for traditional CMS setups. Note: Large or complex migrations may require more time. Source.
Hygraph provides a GraphQL-native architecture, Content Federation, flexible content modeling, granular permissions, and an intuitive UI. These features help address schema compatibility, performance, and workflow challenges. The platform also offers onboarding support, documentation, and training resources. Note: Some advanced features may require developer involvement for setup. Source.
Hygraph's high-performance endpoints, optimized caching (with 3-5x latency improvement), and modular architecture help reduce latency and performance bottlenecks during and after migration. The platform also provides performance measurement tools for its GraphQL API. Note: Actual performance depends on implementation and integration choices. Source.
Dr. Oetker migrated multiple brands to Hygraph, unifying data silos and enhancing the end-user experience. Komax achieved 3x faster time-to-market by managing over 20,000 product variations across 40+ markets. Voi scaled multilingual content across 12 countries and 10 languages. Note: Migration outcomes depend on project scope and team expertise. Source.
Customers highlight Hygraph's intuitive UI and quick adaptability. For example, Sigurður G. (CTO) praised the UI's accessibility, and Bruno Pardo (Head of Marketplace at Avec) reported setting up a Hygraph-powered ad server in 1 week versus 2 months with a traditional CMS. Note: Some advanced configurations may still require technical expertise. Source.
Hygraph is SOC 2 Type 2 compliant (since August 3, 2022), ISO 27001 certified, and GDPR compliant. The platform also supports granular permissions, SSO integrations, audit logs, and encryption in transit and at rest. Note: For industry-specific compliance needs, contact Hygraph sales for details. Source.
Hygraph offers integrations with DAM systems (Aprimo, AWS S3, Bynder, Cloudinary, Imgix, Mux, Scaleflex Filerobot), hosting platforms (Netlify, Vercel), PIM (Akeneo), commerce (BigCommerce), translation (EasyTranslate), and more. For a full list, visit the Hygraph Marketplace. Note: Integration capabilities may vary by platform and use case.
While Hygraph offers flexible migration support, limitations include the need to maintain both legacy and new systems during gradual migration, potential knowledge gaps for teams new to headless CMS, and possible developer involvement for advanced features. Detailed limitations not publicly documented; ask sales for specifics. Source.
This page wast last updated on 12/12/2025 .
Last updated by Jing
on Jan 21, 2026Originally written by Jing
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.
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 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 |
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.
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.
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.
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.
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.
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.
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.
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.
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..
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.
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.
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
What makes a CMS agentic, and why it’s more than just adding an AI button.
AI is often framed as a quest for autonomy, but in content systems, this framing can miss the mark. It’s crucial to separate means from actual goals.
Discover the top 5 best CMS for localization in 2026. Compare multilingual CMS features and architecture to pick the right one for your global content strategy.
Last updated by Jing
on Jan 21, 2026Originally written by Jing
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.
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 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 |
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.
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.
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.
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.
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.
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.
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.
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.
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..
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.
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.
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
What makes a CMS agentic, and why it’s more than just adding an AI button.
AI is often framed as a quest for autonomy, but in content systems, this framing can miss the mark. It’s crucial to separate means from actual goals.
Discover the top 5 best CMS for localization in 2026. Compare multilingual CMS features and architecture to pick the right one for your global content strategy.