Website development and maintenance for acquired brands: a handover guide.

Website development and maintenance for acquired brands should start with an operational handover, not a redesign: secure the domain, accounts and integrations first, then decide what to change. An acquisition can leave your team responsible for a website without control over its domain, its integrations or its support arrangements.

This guide explains how to secure ownership, protect customer journeys and decide which changes belong in routine maintenance, a development project or an emergency response. For the general practice of keeping a site healthy, see our complete website maintenance guide; this article focuses on what changes when the site comes with an acquired brand.

01Why an acquired website needs its own handover plan

The website needs its own handover plan, even when the transaction leaves the brand and the legal entity unchanged.

A functioning homepage does not prove that the business controls the site. Control is often spread across several accounts:

• domain registration and DNS, sometimes with a different provider from the hosting;
• hosting or the website platform, with its own billing details;
• analytics, tag management and search console properties;
• automations owned by a former employee's personal account;
• an agency agreement that covers maintenance without transferring design files, code rights or third-party licenses.

Before making changes, appoint one accountable business owner and one technical lead. The business owner approves priorities and accepts commercial risk. The technical lead validates access, dependencies and recovery options. Give both a shared register rather than scattering handover information across email threads.

Ask transaction counsel to confirm transfer rights and contractual restrictions. Operational access and legal ownership are different questions: a successful login does not establish that an account, a font license or a software subscription can be transferred to the buyer. Domains also follow their own rules. Under ICANN's Transfer Policy, a registrar can apply a 60-day lock on moving a domain to another registrar after a change of registrant, unless the holder opted out beforehand, so plan registrar moves with that delay in mind.

02Website maintenance vs development vs emergency support

Separate recurring upkeep from planned changes before requesting proposals or approving an inherited support agreement. The three categories have different goals, triggers and acceptance criteria.

On a managed platform, infrastructure responsibilities differ from those on a self-hosted stack, so the contract must say what remains your responsibility. Our guide to what website development services should include explains the delivery components worth specifying.

Development and maintenance can share one backlog, but define emergency support separately, with its own coverage hours and escalation routes. An urgent form outage should never compete with a planned landing-page redesign for attention.

03A five-stage handover framework after an acquisition

A phased framework turns an uncertain takeover into decisions that leadership can review and approve. Each stage needs evidence, not just a status label.

This sequence prevents a common acquisition mistake: approving a rebuild before anyone understands the inherited system. Use the business criteria in website priorities for growing teams to assess commercial value, then add acquisition-specific concerns such as transfer rights, seller dependencies and consolidation requirements. Do not advance a stage simply because a transaction deadline has passed.

04Establish a baseline before changing the brand

Record how the website works before changing its design, content, domain or tracking configuration.

• Pages: important landing pages, organic entry pages and a full URL inventory.
• Measurement: conversion events and exported performance data, with date ranges and metric definitions.
• Known gaps: tracking gaps, consent settings and attribution limits, so incomplete data is not mistaken for a reliable benchmark.
• Defects: a list of known issues, with screenshots where useful.

Then test the journeys that matter commercially: submitting an inquiry, requesting a demo, purchasing, signing in or finding support. Follow each action through to its destination. A visible success message is not enough if the lead never reaches the CRM or a confirmation email fails. Keep test records without exposing customer information.

A documented website launch acceptance checklist is a good starting point; add the inherited dependencies to it. The baseline lets the team separate pre-existing defects from problems introduced after the acquisition, and gives the seller, the buyer and the delivery partner a shared reference when the ownership of a defect is disputed.

05Audit integrations and international customer journeys

The dependencies around the website can create more acquisition risk than the pages themselves.

Trace forms, booking tools, payment services, email delivery, consent tools and automation connections. For each integration, record the owner, the billing account, the authentication method and the business purpose. Identify credentials tied to people who are leaving, then rotate them through a controlled process that preserves service continuity, and verify the replacement connection before revoking the old one. Enable multifactor authentication on every administrator account; CISA's guidance on multifactor authentication explains why a password alone is not enough.

Location can also affect acceptance testing. VPNVision's French-language streaming access service illustrates a business proposition built around customers accessing content from abroad. For an acquired brand with a comparable international offer, test country-specific messaging, location-dependent routes and support journeys from the relevant locations, rather than checking everything only from headquarters.

Do not assume inherited customer data can move into the buyer's systems without review. Have legal counsel assess transaction-specific privacy obligations, notices and data transfers. Keep an integration register that records both technical dependencies and unresolved approval requirements. Where a connection cannot transfer, document the replacement and its cutover conditions before closing the old account.

06Prove that recovery works before relying on backups

A backup is useful only if the team knows what it contains and can restore the required service.

Identify the recovery path for pages, CMS content, custom code, media and configuration. Treat CRM records, commerce data and automation settings separately when they live outside the website platform: a site-level restore may not recover them. Confirm what your hosting or platform plan actually provides rather than assuming that managed hosting covers every dependency.

Ask the business owner to define two tolerances: how much data loss is acceptable and how long a critical journey can stay unavailable. Contingency planning frameworks such as NIST SP 800-34 call these the recovery point objective (RPO) and the recovery time objective (RTO). They should drive backup frequency and recovery procedures. A brochure site and a transaction-dependent storefront do not need identical provisions, even with similar page counts.

Test restoration in a safe environment and record the result. Document who can authorize recovery, where credentials are stored and how DNS or integration changes would be reversed. Contracts should distinguish restoration provided by the platform from the provider's responsibility to coordinate recovery across the full customer journey.

07Should you retain, rebuild or consolidate the acquired website?

An acquisition alone is not a reason to replace a website that still supports the business.

A rebuild is defensible when the existing architecture blocks requirements, not simply because the buyer prefers another platform. Decide whether the acquired brand stays independent before committing to a shared domain or design system, and use a shared design and development workflow so commercial decisions and implementation constraints are resolved together.

If URLs must change, the operation becomes a website migration. Create a page-level mapping and test redirects, internal links, canonical references and sitemaps. Follow Google's guidance for site moves with URL changes, which recommends keeping redirects for as long as possible, generally at least one year. When the domain itself changes, Google's Change of Address tool in Search Console tells Google about the move. Our guide to migrating without losing traffic covers the SEO side in detail. Avoid combining an ownership transfer, a domain move, a CMS migration and a full content rewrite unless there is a clear operational reason.

08Match the maintenance schedule to business risk

Set review frequency according to what can fail and the consequence of that failure.

These rhythms are planning starting points, not universal requirements. Add monthly backlog reviews and periodic recovery exercises, and adjust the schedule when the acquired brand's traffic, release activity or commercial dependence changes. Assign an owner to each check and define what happens when it fails: an unchecked monitoring alert provides little protection. For sites that publish often, our guide to maintaining websites that publish frequently covers that operating model.

09Set support expectations you can verify

A maintenance agreement should describe an observable service, not merely promise that someone will look after the site.

• Severity by business impact: an unavailable checkout is not a cosmetic defect on a secondary page.
• Per severity: coverage hours, acknowledgment expectations, escalation contacts and communication frequency.
• Response vs restoration: acknowledging an incident does not mean the service is restored; set both targets.
• Out-of-hours work: state whether it is included or arranged separately.
• Work records: request, diagnosis, change made, tests performed and production outcome, plus approval and rollback information for releases.

For recurring maintenance, ask for exceptions and unresolved risks rather than a report listing only completed tasks. The principles of post-launch website management still apply, but an acquisition also needs explicit seller-to-buyer responsibility boundaries.

Name an acceptance owner on your side. Verify provider work through successful journey tests, resolved alerts and documented changes, not reported hours alone. Keep business-controlled access to the accounts and records needed to change providers later.

10How much does maintaining an acquired website cost?

Budget for inherited complexity, not page count. The initial handover and the ongoing service are different cost categories and should be estimated separately.

The handover may require access remediation, integration replacement, recovery testing, documentation and a one-time technical audit. Ongoing costs depend on platform subscriptions, critical journeys, publishing activity, custom code, support coverage and release volume. An inherited site with few pages can still be expensive to operate if its dependencies are undocumented or tightly coupled.

Request separate scopes for stabilization, routine support and planned development. Ask what happens when included capacity is exhausted, whether unused capacity carries over, and who pays third-party fees and emergency work. Our breakdown of website maintenance pricing factors helps compare offers on obligations and exclusions, not only on monthly price.

An internal team can own priorities and acceptance while an external partner handles specialist delivery. Outsourcing does not remove the need for an accountable buyer-side owner. Ask bidders to state their assumptions so that missing information does not become an unexpected change request once work begins.

11Acquired-brand website handover checklist

Complete these checks before declaring the website operationally transferred, and record evidence for each item.

1. Ownership confirmed: domain registration, platform accounts, billing contacts, transfer rights and administrator access match the agreed ownership structure.
2. Access secured: multifactor authentication enabled, recovery methods documented, seller access removed only after replacement access has been tested.
3. Dependencies recorded: integrations, custom code, licenses, renewals and vendor contacts inventoried, including anything tied to a departing employee's account.
4. Critical journeys tested: inquiries, purchases, sign-ins and support requests reach their intended destination, not just a success page.
5. Baseline preserved: analytics, search data, URL inventories and known defects saved before any brand, domain or tracking change.
6. Recovery demonstrated: restoration tested, with the treatment of CMS content, external data, credentials and configuration recorded.
7. Support agreed: severity levels, coverage, escalation, approval authority and the boundary between maintenance, development and emergency response documented.
8. Open risks assigned: every unresolved issue has an owner, a business impact, a next action and a review date.

Use this checklist as an acceptance record, not a substitute for testing. The site can move into normal operations once the buyer understands the remaining risks and explicitly accepts them. Keep unresolved items visible in the operating backlog rather than closing them when the transaction completes.

12How BeBranded approaches an acquired website

BeBranded starts with consulting before production. On an inherited website, that means mapping ownership, dependencies and critical journeys first, then recommending whether to keep, improve or rebuild the site. The platform follows the need: custom builds on Next.js and Payload, Webflow when it is the right fit, plus AI, apps and automation where they remove manual work. Once the handover is stable, our maintenance and growth service takes over routine upkeep and planned development under one backlog. If you are taking over a site after an acquisition, tell us about your project and we will start from the handover checklist above.