A takeover is more than collecting passwords

A running website or application may hide missing documentation, outdated dependencies, individual-owned accounts, untested backups and years of technical debt. A responsible provider cannot commit to full operations based on a URL and one administrator password. A structured takeover audit must come first.

Why inherited systems are risky

A new project controls its architecture. A takeover inherits previous compromises, undocumented rules, data-quality problems, permission issues, external dependencies, licence conditions and technical debt.

What we review

Business and functional context

Understand critical workflows, users, peak periods, known defects, expected changes and the business impact of failure.

Access inventory

Identify domain, DNS, hosting, source control, CI/CD, databases, administration, email, APIs, payment, billing, app stores, analytics, monitoring, backups and secrets. Replace shared accounts with named users, correct roles and MFA.

Ownership and contractual position

Clarify ownership of domain, source code, licences, design, media and third-party contracts.

Source code and version control

Verify that the repository is complete, matches production, can be built, contains no embedded secrets and has a workable release process.

Dependencies and supply chain

Review versions, support status, known vulnerabilities, origin, licences and build reproducibility. Modern application security includes the software supply chain, not only custom code.

Data and databases

Review schema, integrity, duplication, size, backup, retention, deletion, performance and customer-data separation.

Infrastructure

Map operating systems, runtime, containers, networking, TLS, resources, logs, jobs, scaling constraints, staging and single points of failure.

Security

Review authentication, administrative access, roles, public endpoints, secrets, uploads, logging, rate limiting and personal-data access. A full penetration test may remain a separate scope.

Monitoring and recovery

Check real backup results and, where possible, perform a test restoration. Review uptime monitoring, application logs, alerts, retention, off-site copies, restore procedures, RPO and RTO.

A 30/60/90-day stabilisation plan

  • First 30 days: secure access, critical backups, monitoring, P0/P1 risks and minimum documentation.
  • Days 31-60: dependency updates, staging, release process, core tests, database and logging improvements.
  • Days 61-90: technical-debt roadmap, refactoring priorities, broader automated tests, safe feature planning and final SLA model.

When should a provider refuse the takeover?

Refusal may be responsible when legal access or source code is unavailable, ownership is unclear, critical security work is rejected, expected SLA is impossible without infrastructure or rebuilding is more economical than repair.

The BT Digital approach

We do not promise unlimited support before understanding the inherited risk. We perform a focused audit, prioritise findings and propose a stabilisation plan.

The goal of a takeover is not to modify the system as quickly as possible, but to bring operation, access and responsibility back under control.