Consolidating websites after an acquisition

Consolidating websites after a merger or acquisition: why it differs from a normal rebuild

Consolidating websites after a merger is mainly an inventory, data, redirect and access problem, and the CMS choice follows from those. A newly combined group usually inherits several sites on different platforms, some of them past end of life, and a deadline set by the integration plan. A normal rebuild starts from the brief the business writes. A consolidation starts from what already exists: every domain, every page that ranks or receives links, every form and integration, every editor account and every piece of content that someone is legally or commercially bound to keep. Until that inventory exists, no platform choice can be defended. Drupal 7 deserves early attention because its security support ended on January 5, 2025, and Drupal 6 and 7 sites cannot simply be updated to Drupal 10 or later. They are migrated into a new site, and their themes must be rebuilt. Confirm the exact version and PHP runtime of each acquired site before you set a timeline.

The acquired estate may also hold EU personal data, regulated content or both, which changes who can touch the systems and where they can sit. If a non-EEA acquirer's staff can reach an EU target's CMS, database or form submissions for support or administration, that remote access can count as a transfer under EDPB Guidelines 05/2021 and needs a Chapter V transfer tool. Financial services and healthcare sites may carry rate disclosures, clinical or ePHI-adjacent forms, or content that needs a documented review trail, and those obligations follow the content into the merged estate. Ask counsel and the compliance lead to classify each site before migration begins, and record the classification in the inventory.

For a multi-brand estate with shared components, Drupal is usually the stronger short answer; for a smaller, simpler set of brochure sites, WordPress is often enough. Drupal supports multiple sites, shared themes and granular roles, which matters when several brands must keep their identity while sharing a design system and a governance model. WordPress can serve a handful of sites well, but its governance and multi-brand controls depend more on plugins, so the review burden grows with the estate. Either way, confirm the current maintenance policy of the release line you plan to run, because the choice only holds if security patches reach you on time.

Which regulations and contracts shape the consolidation

This table lists the rules that apply to a combined group when web estates are merged, and what each one means for the build. Applicability depends on the sector and legal status of both the acquirer and the target, so confirm each row with counsel before scoping. The main takeaway is that the regulatory evidence (access records, processor terms, exit plans and end-of-life dates) must exist before the first site moves.

Requirement	What it asks for	What it means for the build
SEC internal control and disclosure (public registrants)	Management may exclude a newly acquired business from its internal control assessment for a limited period, but must disclose the exclusion and its significance. IT general controls cover program changes and access to programs and data.	Keep change records, access reviews and approval trails for the consolidated CMS, since the acquired site may fall outside the assessment for a time. Confirm with counsel and auditors whether web publishing controls are in scope.
SEC cyber incident disclosure (public registrants)	Material cybersecurity incidents require a Form 8-K Item 1.05 filing, generally within four business days after materiality is determined. Annual reports must describe oversight of third-party providers.	Migration periods leave legacy and new sites exposed at once. Document who declares materiality, how host and agency incidents reach that group, and which vendors are covered.
NIS2 contact and change notification (EU)	In-scope entities give their competent authority their name, contact details, IP ranges, sector and service countries, and report changes without delay and within two weeks at most.	Each new domain, hosting range or CDN change created by consolidation can alter the registered details. Assign an owner to update the register whenever a site or IP range moves.
DORA register and exit planning (EU financial entities)	A register of ICT service arrangements is required at entity and group levels, and tested exit strategies and transition plans are required for services supporting critical or important functions.	Record the CMS host, agencies, CDN and plugin or module suppliers as ICT arrangements. Treat the acquired platform retirement as an exit exercise with a documented, tested plan.
EU Data Act switching rights	Data processing providers must support switching to another provider or on-premises infrastructure, with a maximum two-month notice period, a 30-day transitional period, porting of exportable data, and no switching charges from 12 January 2027.	Relevant when the acquired estate runs on a hosted or SaaS CMS. Confirm contract notice terms and export formats early, because the no-charge date falls within many consolidation timelines.
GDPR processor instructions and records (EU)	Processors act only on the controller's documented instructions, including for transfers, and processing records describe Article 32 security measures where possible.	Update processor agreements and instructions for every host, agency and form tool that receives submissions from the merged sites. Keep the processing records in step with the new site map.
EDPB remote access by a non-EEA acquirer (EU)	Under EDPB Guidelines 05/2021, remote access to EU personal data from a third country, including support or administration, is a transfer requiring a Chapter V transfer tool.	If staff of a non-EEA acquirer will administer or view the EU target's CMS or form data, put a transfer mechanism in place before access is granted. Limit administrative access by role and location during the migration.
HIPAA business associate terms (US)	Business associate contracts must require Security Rule compliance, flow terms down to subcontractors that handle ePHI, and report security incidents to the covered entity.	Sites with appointment, patient or benefits forms need business associate terms with the hosting, agency and plugin providers. Confirm which pages and forms touch ePHI before the content inventory is final.
PCI DSS validation (where checkout is involved)	Validation is documented with official PCI SSC templates and an Attestation of Compliance. The payment brands, not the PCI SSC, decide which entities must validate.	Any migrated checkout, payment page or script change can change the cardholder data environment. Ask the payment brands or acquirer which validation applies before redirect or payment changes go live.
Drupal 7 end of life (Drupal estates)	Drupal 7 security support ended on January 5, 2025. Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later and must be migrated into a new site with rebuilt themes.	Acquired estates still on Drupal 7 need extended security support or a rebuild on a supported version, and themes must be rebuilt. Plan migration as a new build rather than an upgrade.
Drupal 10 end of life (Drupal estates)	Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule. Drupal 12 requires PHP 8.5 or later.	Any Drupal 10 site in the consolidated estate needs a move to Drupal 11 or 12 before that date, with PHP versions and contributed modules checked against the target release.

Three consolidation paths and when each fits

This path adds the acquired sites as new sites inside a Drupal or WordPress multisite that already runs the parent company's estate. It fits when the parent platform is current, the acquired estate is modest in size, and the brands can share a design system with variations rather than separate looks. Shared components, one editorial model and one release process keep ongoing cost lower than running parallel stacks.

Shared upgrade path: Core and module updates apply once across all sites, so the acquired brands inherit the parent's security release cadence.
Governance load: Every acquired brand needs its own editors, roles and approval chain, and a single misconfigured permission can expose another brand's content.
Theme isolation risk: Brand-specific CSS and templates must be kept apart from the parent's theme, or a change for one brand breaks another.
Drupal 6 and 7 sources: Such sites are not upgraded in place. They are migrated into a new site with the core Migrate, Migrate Drupal and Migrate Drupal UI modules or with Drush, and their themes must be rebuilt.
Multisite limits: Confirm how many sites and languages the chosen configuration handles well before committing.

Check whether the parent platform is within its supported release window and whether your team can run a multisite without adding headcount.

Which open source CMS platforms fit an acquisition estate

An acquisition estate usually mixes brands with different audiences, editors and maturity levels. The options below differ in how they separate brands, how much editorial structure they give marketing teams, and how much front-end work they need, so the choice should follow the brand model you plan to keep. Each card names the license fact and the test to run before you commit.

Drupal core for multi-brand governance

Drupal core is licensed under GPL-2.0-or-later and has no paid edition, so the license cost is zero and the budget goes to design, build and support. For an acquisition, brands are usually separated with a multisite setup (one codebase, several sites) or separate installs that share a theme base and modules. Multi-brand governance is configured through roles and permissions per site or content section, shared content types and a single update pipeline. Test whether the acquired brands can share one codebase without sharing editors, data or theme overrides that they must keep.

Drupal CMS 2.0 for marketing teams

Drupal CMS is a distribution built on Drupal core for marketers and content teams, with recipes, site templates, the Drupal Canvas visual page builder and optional AI tools. It fits a post-deal period when the acquirer's marketing team must stand up landing pages and campaign sites for several brands quickly. Recipes and templates reduce repeated setup, but they also lock in choices about content types and layouts. Test whether the templates match the brand guidelines of each acquired company and whether Drupal Canvas can enforce brand components without custom code.

WordPress for lean brand sites

WordPress is a practical choice for smaller brand sites that need a simple editorial model and a wide pool of developers. WordPress.org states that only the most recent release in the 7.1 series is actively maintained, so the estate must follow point releases closely rather than staying on an older branch. Brand separation usually means separate installs or WordPress multisite, with plugin choices made per brand. Test how many third-party plugins each brand depends on, since each one needs its own update and review path, and confirm that your editorial workflow and permissions can be kept consistent across brands.

Headless Strapi, Payload or Directus

A headless CMS fits only when acquired brands need a separate front end, a native mobile app or content delivered to several channels from one API. Strapi is MIT licensed except components under ee directories, which form its separately licensed Enterprise Edition. Payload is MIT licensed, and Directus is licensed under the Monospace Sustainable Core License 1.0, which permits internal use and professional services to deploy or host it for a licensee. Test which license terms apply to each feature you need, and confirm how roles and content ownership are modeled per brand in the API.

Protecting search rankings, redirects and brand identity during the move

Consolidation is where organic search traffic is most at risk. Every acquired URL that moves to the surviving platform needs a mapped destination, or search engines and visitors land on errors and lose the ranking signals those pages earned. Build the redirect map from three sources: the content inventory, which shows every live URL and its owner, the analytics history, which shows which pages still receive visits and links, and the server logs, which show which legacy paths are requested by crawlers and partners. The sitemap alone misses orphaned pages, old campaign URLs and deep documents that other sites link to. Agree the mapping rules with the SEO lead before any content moves, and confirm with the hosting team how redirects will be served (CMS module, web server rules or CDN), since redirect chains and loops are easy to create when two layers both rewrite the same path.

Multi-brand theming works best on one codebase with shared components and brand-specific tokens. Keep layout logic, navigation patterns, forms and accessibility fixes in shared components, and place brand colors, typography, logos and imagery in per-brand design tokens and templates. Legal footers, regulatory disclosures, pricing notes and regional content should be stored as brand- or market-scoped content rather than hard-coded into templates, so that a change to one brand's disclosure cannot leak into another's pages. Confirm with legal and compliance which disclosure text each brand must show and in which jurisdictions. Do not copy the acquired site's theme into the new platform. Rebuild it on the target design system, because copied theme code carries the old platform's markup, asset pipeline and accessibility defects into the new estate.

Measure the move against a baseline taken before launch. Export search console data, organic landing page reports and top-linked URLs for the acquired sites before cutover, then compare them at fixed intervals after launch, watching for crawl errors, redirect chains, indexing drops and pages returning 404 or soft 404 responses. Track brand-specific pages separately so a problem on one acquired brand is visible quickly. Keep the old platform running in read-only mode for long enough to cover the redirect monitoring period, and agree the retirement date only after the team has reviewed these reports. Ask the implementation partner to document the redirect map, theme token inventory and monitoring plan as deliverables so the owning team can maintain them after handover.

Which systems the consolidated CMS must connect to

A merger multiplies the systems a web estate depends on, and each connection carries personal data, consent state or access rights from one legal entity to another. The cards below cover the integration points that most often break during consolidation, with the data that moves through each and the controls to confirm before the acquired platform is switched off.

Single sign-on for editors and visitors

Editors from both companies need one controlled way in, and the acquired brand's staff should not keep accounts on a platform being retired. The samlauth module lets a Drupal site act as a SAML service provider, while the OpenID Connect module lets an external provider such as Okta authenticate users and create accounts on first sign-in. Data moving: usernames, email addresses, group claims and role mappings. Confirm: which identity provider is authoritative for each acquired brand, how group claims map to Drupal roles, and how leavers are deprovisioned in the CMS.

Lead and form data to CRM

Forms on acquired sites often push leads straight into a CRM or marketing automation tool that the acquirer may not own. Each form endpoint is a data flow that needs a documented purpose, a named recipient and a retention rule. Data moving: names, contact details, company, product interest and consent choices. Confirm: which CRM instance receives each brand's leads, whether consent text is stored with each record, and whether any recipient sits outside the EU or the US before data is sent.

Analytics and consent tooling

Merged estates often run two tag managers, two analytics properties and two cookie banners, which produces conflicting consent states and duplicate tracking. Consolidation is the point to decide one consent model and one measurement scheme across brands. Data moving: page views, identifiers set in cookies, and consent records. Confirm: that each tag fires only after the matching consent choice, that the acquired brand's analytics property has an owner, and where the consent log is stored.

Site search and index data

Each acquired site may index its own content in a separate search service, and product or document content can end up copied into a third-party index. Consolidating search changes what is indexed, who can query it and how long index copies remain. Data moving: page content, product records and query logs. Confirm: which search index serves each brand, whether query logs contain personal data, and whether the index is removed when the acquired site is retired.

Payment and application handoffs

Where an acquired site hands visitors to a payment page, a loan or quote application, or an enrolment form, the handoff is a control point for cardholder or applicant data. Some of these handoffs carry payment data that falls under PCI DSS, and the payment brands and acquirer decide who must validate. Data moving: redirect parameters, session tokens and applicant details. Confirm: which entity owns each handoff, the validation status the acquirer requires, and that no card data touches the CMS.

Hosting boundary and data location

After a cross-border acquisition, the acquired site may be hosted in a region or account that the acquirer's policies do not allow, and editor access from a new jurisdiction can itself be a transfer. Hosting, backup, CDN and support access each define where data sits. Data moving: all site content, editor accounts, logs and backups. Confirm: the hosting region for each brand, which staff in which countries can reach production, and where backups and logs are kept, with the evidence written down.

How consolidation is phased, and what each phase produces

The sequence moves from an honest inventory of the acquired estate to a governed target, a proven pilot, controlled batch moves and a documented shutdown of the old platform. Each phase ends with a named artifact that the next phase depends on. Timing depends on the number of sites, languages and data volume, and must be set in the written scope.

Inventory content and assign ownership
DeployOpen works with the acquirer and the acquired team to crawl every domain, subdomain and microsite, then list pages, documents, media, forms, integrations and third-party scripts. Each item receives a named business owner, a content type and a traffic or search value where analytics data exists. The output is the inventory register, and the step is done when every site has an owner who has confirmed the list in writing.
Classify data and regulatory exposure
Each site and form is tagged by the data it collects, the jurisdictions its users and servers touch, and any sector rules that apply, such as personal data under GDPR, health information, payment pages or public-sector accessibility duties. Where a non-EEA acquirer's staff will reach EU systems during the move, the transfer basis is recorded before access is granted. The output is a classification register that drives hosting, access and evidence decisions in later steps.
Design the target architecture and governance model
The team decides how the combined estate will be structured, whether as one multi-site installation, shared components on a common design system with per-brand themes, or separate installs with shared code. It also defines roles for global, brand and section editors, approval states, and who may publish to which domain. The output is an architecture decision record and a signed-off permission matrix, which the business owners approve before any build work starts.
Pilot one acquired site with redirect testing
One modest acquired site is rebuilt on the target platform with its theme, content types and forms, then migrated into a staging environment. Every legacy URL is crawled against the new site, and the redirect map is tested for status codes, chains, loops and canonical tags. The output is the pilot migration report and a tested redirect map, and the step closes only when stakeholders accept the content, permissions and search impact findings.
Migrate remaining sites in brand batches
Remaining sites move in batches grouped by brand or by shared regulatory profile, so that one theme, one set of editors and one set of integrations are tested at a time. Each batch is verified against the inventory register, with content counts, media links, form submissions and user accounts reconciled. The output is a migration evidence pack per batch, including reconciliation logs, test results and any exceptions with their owners.
Cut over and monitor search and errors
DNS, redirects and authentication are switched for each batch during an agreed window, with rollback steps written down in advance. For a defined period after cutover, the team monitors crawl errors, 404 responses, search console warnings, form delivery and login failures against the redirect map. The output is a cutover record with monitoring results, and the batch is closed when agreed thresholds in the written scope are met.
Retire the acquired platform
Once every site has been verified and the retention period agreed with legal and records owners has been applied, the acquired platform is archived and then decommissioned. Credentials, integrations, backups, certificates and third-party accounts are revoked or closed, and any data that must be retained is exported and stored under the classification rules. The output is a decommissioning record that lists each system, the date it was shut down and who approved it.

What auditors and regulators ask to see after consolidation

This table lists the evidence that auditors, regulators and acquirer's counsel usually request after websites from an acquired business move onto the surviving CMS, with the component that produces each item. Read it as a checklist to agree on before cutover, because some records must exist at the start of the project rather than be reconstructed later. DeployOpen prepares this evidence for your assessors; it does not issue audit reports or attestations.

Evidence requested	What it shows	Component that produces it
Content and system inventory	Every site, domain, language, form, integration and owner in both estates, with the decision taken for each	Pre-migration crawl and inventory export, CMS site and content type listings, and the signed-off disposition register
Data flow and transfer records	Where site data, form submissions and editor accounts are stored and which parties can reach them, including any non-EU access by an acquirer	Hosting configuration, third-party script and SaaS add-on list, and network access rules kept with the processing records
Records of processing and processor instructions	Processing activities for the migrated sites, the Article 32 measures applied, and documented instructions to any processor	Records of processing under GDPR Article 30 updated for the new platform, plus contracts and written instructions to hosting and support providers
Third-party and vendor contracts	Which providers now host, support or patch the estate, and the flow-down terms that apply to them	Contract register, subprocessor list, and for US health content, business associate terms under 45 CFR 164.314(a) where applicable
DORA-style register entries	For financial entities, each ICT service arrangement supporting the web estate and the exit plan for it	Register of information entries maintained by the entity, with exit and transition notes drawn from the decommissioning plan
Redirect and SEO test results	Old URLs mapped to new ones, the status codes returned and the search visibility checks run before and after cutover	Redirect map file, crawl comparison reports and server logs showing 404 and redirect-chain counts
Migration validation records	Proof that content, media, metadata, users and workflow states arrived complete and unchanged	Migration reports from the migration tooling, sample-based content comparison sign-offs and rollback test records
Access reviews for editors and administrators	Who holds editor, publisher and administrator roles on each brand site, when access was granted and when it was last confirmed	CMS audit logs, role and permission exports, and identity provider group membership reports
Decommissioning record for the legacy platform	Evidence that the acquired platform was shut down, its data retained or deleted under policy, and its credentials revoked	Hosting teardown records, backup retention settings, certificate and DNS change logs, and destruction or archive certificates
Cybersecurity oversight of third-party providers	For a US public registrant, how management oversees cyber risk from the providers that run the consolidated sites, and what would be disclosed after an incident	Vendor security review records, incident notification terms in contracts, and the incident response runbook for the web estate

What to ask an implementation partner before consolidating

Start with data classification, because it decides which transfer tools apply before any content moves. Ask the partner to classify every acquired source by data type: EU personal data, ePHI, payment-related data, form submissions and editor accounts. Then ask which transfer tool covers acquirer staff who will view or administer an EU target's systems from outside the EEA. Under EDPB Guidelines 05/2021, remote access from a third country is a transfer, so the partner should show where a Chapter V tool is required and how processor work follows the controller's documented instructions under GDPR Article 28(3)(a). Ask for the updated records of processing under Article 30 and a list of every acquirer account with its country of access.

Next, ask how the redirect map and the migration are proven before cutover. Request a crawl-based inventory of every acquired URL, a redirect map with one destination per legacy URL, and staging tests that confirm each mapped path returns the intended status code and destination before DNS changes. For a Drupal 6 or 7 source, ask whether the migration uses the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush, and which themes will be rebuilt, since Drupal.org documentation states that these themes cannot be migrated. Ask how brand-specific legal notices, privacy terms and regulated product disclosures are assigned to the owning legal team for approval before they go live.

Ask how acquired users sign in. The SAML Authentication module lets a Drupal site act as a SAML service provider, and the OpenID Connect module creates accounts on first sign-in, so confirm which identity provider the acquirer uses, how existing editor accounts map to roles, and how accounts that should not exist are blocked. Ask how the legacy platform is retired: a dated export of content, assets, users without password data, form submissions and logs, a read-only archive with a retention period set by legal, and a plan to decommission DNS records and certificates. Finally, ask what the partner will not claim. Partners prepare controls and evidence, but independent auditors issue audit reports and certification bodies issue certifications. Require a written scope with deliverables and acceptance criteria before work starts.

Questions buyers ask about consolidating after an acquisition

What drives the cost of consolidating acquired websites onto one CMS?

Cost is driven by the size and shape of the estate: the number of sites, languages, content volume, brands and editor groups, plus the source version each site runs on. Regulatory exposure adds work, because accessibility conformance, records of processing and transfer documentation each need their own review and evidence. Drupal and WordPress carry no license fee, so the spend is on people and infrastructure: design and build, multi-site architecture, content migration, redirect mapping, testing, hosting, CDN and ongoing security updates. Ask any partner to split the quote into one-time work (inventory, design, migration, cutover) and recurring work (hosting, patching, support), and to show which inputs each line depends on.

How long does a website consolidation after an acquisition take?

Duration depends on the same inputs as cost: how many sites are in scope, how much content must be inventoried, decided and moved, and how many brands must be themed and governed separately. The timeline is set in the written scope, which lists deliverables, dependencies and acceptance points before work starts. Delays usually come from slow decisions on brand rules, missing content owners and late sign-off on redirects, not from the platform itself. Ask for a phased plan that separates the first cutover from the retirement of the acquired platform, since the second phase often waits on DNS, email and reporting changes.

What does the acquiring team need to provide before consolidation starts?

The acquiring team needs to provide access to the acquired estate, including the CMS admin, hosting accounts, analytics, search console data and a current list of domains. It also needs a named owner for each site, a decision maker for brand governance (which brands stay, which templates they share and what the design system allows), and an approver for redirect rules, legal pages and cutover. Without those names and decisions, a partner can inventory content but cannot finish it. Put these responsibilities in the scope so that delays in client decisions are visible and can be priced as change requests.

Can our internal IT team consolidate the websites alone?

A capable internal team can handle a small estate with one brand and one CMS version, especially if it has done a migration before. Trouble usually starts when the work spans several brands, languages and editor groups at once, or when the acquired platform is a proprietary system with little export support. Other common gaps are redirect planning that protects search rankings, accessibility testing across templates, and cutover timing that does not disrupt campaigns. Many teams keep brand decisions and content ownership in-house and bring in a partner for migration engineering, testing and the security review that the cutover requires.

How should EU personal data and non-EEA access be handled during integration?

Start by mapping where each site's personal data, editor accounts and form submissions are stored, and which people or systems can reach them. Under EDPB Guidelines 05/2021, remote access to EU personal data from a third country, including for support or administration, counts as a transfer, so giving a non-EEA acquirer's staff access to an EU target's systems requires a Chapter V transfer tool. GDPR Article 28(3)(a) also requires processors to act only on the controller's documented instructions, including for transfers, and Article 30 records should describe the Article 32 measures. Confirm these points with counsel before granting access, and keep the mapping as evidence.

What should we do with Drupal 7 sites that cannot migrate in time?

Drupal 7 security support ended on January 5, 2025, according to Drupal.org, so any remaining Drupal 7 site needs a plan. Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later; they are migrated into a new site with the core Migrate, Migrate Drupal and Migrate Drupal UI modules or with Drush, and themes must be rebuilt. If a site cannot move before the acquisition's cutover, the Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites in that position. Treat that as a bridge with its own cost and end date, and confirm it with the vendor before relying on it.

What compliance evidence should be kept during an acquisition migration?

Keep a dated content and redirect inventory, the decisions that shaped brand governance, the access and permission map, and the transfer documentation for any cross-border access. If the acquired business is a public company, its ICFR reporting may exclude the new business for a limited period, but the exclusion and its significance must be disclosed, so IT general control evidence for any web system that supports financial reporting should be kept. For regulated sectors, review business associate or processor terms before any shared hosting or support. Ask your auditor which records they will request, because DeployOpen prepares evidence but does not issue audit reports or certifications.

How DeployOpen scopes and runs a post-acquisition consolidation

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a post-acquisition web consolidation, that means agreeing a written scope for the content inventory, redirects, theming, permissions and retirement of the acquired platform before any build work starts.

How we scope

Written scope covers the acquired and target web estates, the sites in each, and the brands to be merged
Content inventory lists pages, owners, languages, forms, integrations and the data each site collects
Redirect and SEO plan is agreed in writing, including the URL map and the analytics continuity checks
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts

How we build

Multi-brand theme and shared components are built on the target platform, with each brand's design tokens kept separate
Editor roles, permission groups and approval workflows are mapped from the acquired platform to the target
Content migration scripts are tested on copies of the source data and checked against the inventory before cutover
Accessibility and security testing run on each brand site before the redirects go live

How we hand over

Runbooks cover deployment, backup, restore, redirect maintenance and user administration for the consolidated estate
Architecture, configuration and permission decisions are documented so your team can audit them later
Evidence for compliance reviews, such as access reviews and change records, is packaged with the handover
The acquired platform is retired on a written plan that confirms data export and the final archive copy

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover
Retainers can cover platform patching, redirect monitoring and onboarding of new brand sites
Support scope, response expectations and service levels are written into the agreement, not assumed
Confirm with us during scoping which post-cutover support model fits your governance and procurement rules

Consolidating websites after a merger or acquisition