From a fragmented website estate to a clear digital platform blueprint

An established multi-brand organization approached me with what initially sounded like a technology migration: replace an increasingly difficult legacy CMS with a modern headless platform.

The technology choice was only the visible part of the problem.

Behind it sat a much larger digital ecosystem: multiple brand websites, campaign pages, specialist content properties, product information, downloadable resources, editorial workflows, customer-facing forms, internal approval processes, and several existing business systems. Routine website changes depended too heavily on developers, content approvals happened across disconnected tools, and teams lacked a shared model for who owned what.

Before committing internal development capacity to a rebuild, the organization needed to define what the future platform should own and how the organization would operate it.

I led a focused discovery and architecture engagement to define that foundation.

At a glance

The challenge

The organization had accumulated a valuable but fragmented digital estate over time.

Different websites and campaign properties had grown through separate initiatives. Content lived across the CMS, external platforms, shared drives, specialist business systems, and manually maintained pages. Marketing teams could not safely manage many routine changes without involving developers, while broad CMS access would have introduced unacceptable publishing and compliance risk.

The visible symptoms included:

• Too many small website changes passing through developers.
• Repeated pages and campaigns being rebuilt or updated manually.
• Approvals coordinated through project management tools, messages, email, and follow-up.
• Content and assets duplicated across systems.
• Difficulty tracing where products, claims, images, or other regulated references appeared.
• Unclear boundaries between the CMS and existing operational systems.
• Concern about migration risk, SEO preservation, and business continuity.
• Different teams needing autonomy without unrestricted control over the platform.

A direct rebuild would have carried a significant risk: reproducing the same fragmentation inside a newer CMS.

Looking beyond the CMS migration

I began by treating the website as part of a wider operating system rather than an isolated collection of pages.

For each important area, the discovery clarified:

• The business process hidden behind each page or feature.
• The teams responsible for creating, reviewing, approving, and publishing content.
• The system that should act as the source of truth.
• The functions that should remain integrated rather than rebuilt.
• The points where the current process depended on manual coordination.
• The decisions that would be expensive to reverse after implementation began.

This changed the engagement from a CMS configuration exercise into a digital platform and operating-model review.

Discovery across the full ecosystem

The work combined business discovery with hands-on technical investigation.

I reviewed the existing website estate, recurring content types, page structures, administrative workflows, analytics signals, migration constraints, design prototypes, infrastructure, and connections to external systems. I also held focused discussions with digital, marketing, design, technical, operational, and governance stakeholders.

The discovery covered six connected areas.

1. Platform responsibility

I defined what the future CMS should own and, just as importantly, what should stay outside it.

The organization already had specialist systems responsible for product information, customer data, operational processes, and approved assets. Rebuilding those functions inside the CMS would have duplicated business logic and created new sources of truth.

The recommended model positioned the CMS as the controlled website content, workflow, and publishing layer, connected to authoritative upstream systems through clear references and integrations.

2. Multi-brand content architecture

I designed a shared foundation that could support multiple brands, sites, campaign properties, languages, and future regional expansion without mixing content or permissions that needed to remain separate.

This included recommendations for:

• Shared and brand-specific content.
• Reusable page patterns and controlled content blocks.
• Navigation, global settings, and site configuration.
• Cross-site taxonomies and relationships.
• Multilingual content and translation workflows.
• Future sites and campaigns without repeated platform setup.

3. Controlled editorial autonomy

The central operating principle became controlled autonomy.

Marketing and content teams needed to manage the work they genuinely owned, but that did not mean turning the platform into an unrestricted visual page builder.

I recommended a model in which editors control content, approved assets, references, calls to action, scheduling, and selected optional sections. Core templates, layout logic, integrations, and compliance-sensitive structures remain governed by design and development.

This gives internal teams useful independence while protecting consistency, maintainability, and information integrity.

4. Roles, approvals, and governance

I translated organizational responsibilities into a practical publishing model.

The blueprint addressed:

• Role and permission boundaries.
• Content creation, review, approval, and publishing states.
• Different workflows for different content types.
• Multiple reviewers where genuinely required.
• Notifications and audit history.
• Translation and external contributor access.
• Avoiding unnecessary approval steps that would create new bottlenecks.

The goal was not to digitize every existing handoff. It was to simplify the workflow before implementing it.

5. Migration and SEO protection

Leadership needed confidence that the transition could happen without losing valuable content, search visibility, or operational continuity.

I developed a parallel migration strategy in which the existing estate would remain available while the new platform was built, populated, and validated.

The migration framework covered:

• Content and URL inventory.
• Structured mapping from legacy content into the future model.
• Automated extraction where reliable.
• Manual review where source data was incomplete or inconsistent.
• Decisions to keep, rebuild, consolidate, redirect, retire, or defer content.
• Metadata, structured data, redirects, and search preservation.
• Programmatic comparison and human quality assurance.
• Acceptance gates before traffic moved to the new platform.

This turned migration from a late-stage content task into a planned workstream with explicit ownership and risk controls.

6. Phased implementation

The organization did not need to solve every digital ambition in the first release.

I separated the foundational decisions from later enhancements and proposed a phased rollout. The first implementation would establish the shared platform, core content model, permissions, workflows, integrations, and migration architecture. Subsequent brands, sites, asset capabilities, and advanced workflows could then build on the same foundation.

This allowed the team to move forward without either narrowing the architecture to one immediate website or expanding the first release into an unmanageable transformation programme.

The recommended direction

The final recommendation was a unified, multi-site and multilingual headless platform with clear responsibility boundaries.

In the proposed model:

• The CMS owns website content, reusable templates, editorial workflows, approvals, and publishing.
• Specialist business systems remain authoritative for their own data and processes.
• Approved assets come from a governed source rather than uncontrolled uploads.
• Content references are structured so teams can identify where important entities appear.
• Brand and site boundaries are enforced through permissions and tenancy rules.
• Internal teams gain autonomy through purpose-built workflows, not broad administrative access.
• Implementation starts with the highest-priority site while preserving a foundation for the wider estate.

The key was not centralizing everything in one application. It was creating one coherent operating model across connected systems.

The outcome

The engagement produced a detailed, implementation-ready digital platform blueprint.

It gave leadership and delivery teams a shared reference for:

• The recommended platform architecture.
• System ownership and integration boundaries.
• Multi-brand and multilingual structure.
• Collection and content-model direction.
• Reusable templates and controlled page flexibility.
• Editorial roles, permissions, and approval workflows.
• Asset governance and source-of-truth responsibilities.
• Migration sequencing, validation, and SEO protection.
• Infrastructure and maintainability considerations.
• Risks, assumptions, unresolved decisions, and responsible owners.
• A phased implementation roadmap.

The blueprint was delivered as an interactive reference rather than a static report alone. Stakeholders could move between executive and detailed views, search the recommendations, review connected decisions, leave contextual feedback, and ask questions against the material.

Why the engagement mattered

Without discovery, many of the most consequential architecture decisions would have been made implicitly during development.

That would have meant designing permissions, data ownership, content relationships, migration rules, and system boundaries while code was already being written. Changing those decisions later would have required reworking schemas, integrations, workflows, and migrated content.

The discovery phase gave the organization something more valuable than a feature list: a shared model of the future platform and a safer basis for investment.

It also gave the internal implementation team enough specificity to move forward without turning the blueprint into a rigid specification that ignored what would be learned during delivery.

The broader lesson

A CMS migration is rarely only a CMS migration.

When an organization has multiple websites, teams, systems, and approval responsibilities, the real challenge is deciding how the entire digital operation should fit together.

The right starting point is not a backlog of pages to rebuild. It is a clear understanding of ownership, workflows, source systems, migration risk, and the decisions that will shape everything built afterward.

That is what this engagement established.