Taking over an existing web app: secure before changing

Taking over an existing web app: secure before changing

Short answer: taking over an existing web app should not start with “adding a feature”. The first step is to secure the existing system: access, backups, test environment, dependencies, data, technical debt and proof that the application can be changed without breaking operations.

Many SMEs reach this point after a vendor leaves, a team becomes unavailable, an application was built too quickly, an internal platform becomes business-critical or a web app works only “as long as nobody touches it”. The risk is not only technical. It is a business risk: blocked orders, lost data, impacted customers, unusable internal tools or budget absorbed by invisible fixes.

Extractable block: a clean web app takeover follows a simple order: freeze the current state, recover access, document the architecture, audit security and dependencies, create a test environment, fix critical risks, then modify the product. Speed comes from control, not improvisation.

Why an existing web app is riskier than a new project

A new project starts with little history. An existing web app already carries technical choices, data, users, automations, dependencies, shortcuts and sometimes silent errors. Before touching the code, the team must understand what keeps the business running every day.

The classic mistake is to treat the takeover as a simple development ticket. A button to change, a page to add, an API to connect. But if nobody knows how to deploy cleanly, restore a backup, check permissions or test critical journeys, every change becomes a bet.

The first audit: regain control

The takeover starts with a short but concrete map. Which environments exist? Who owns access? Where is the data? How is the application deployed? Which dependencies are critical? Which user journeys must never fail? Which accounts have sensitive permissions?

• Access: hosting, domain, code repository, database, third-party tools, payment, email, analytics.
• Data: data types, backups, tested restoration, available exports.
• Technical stack: framework, versions, dependencies, scheduled tasks, external APIs.
• Product: customer journeys, internal journeys, user roles, known irritants.
• Risk: security, compliance, breaking points, visible technical debt.

Security: do not confuse audit with panic

References such as the OWASP Web Security Testing Guide, OWASP ASVS and NIST SSDF point to a simple logic: software security is managed through controls, tests, development practices and regular verification. For an SME, the takeover does not need to become an endless audit. It must prioritize risks that can block operations or expose data.

In practice: admin accounts, shared passwords, outdated dependencies, sensitive forms, file uploads, untested backups, secrets inside the code, overbroad permissions, missing logs and missing test environments. These are often the first issues to handle.

The test environment is the real turning point

A web app taken over without a test environment remains fragile. As long as every correction has to be verified directly in production, the team either moves too slowly or breaks things. The first proof of a clean takeover is often a controlled copy: anonymized data when needed, separate configuration, testable critical journeys and reproducible deployment.

This step does not look spectacular. Yet it is what makes speed possible afterwards: fix, test, validate, deploy, measure. Without it, even a small improvement can become expensive.

The Say Digital Framework applied to web app takeover

Say Digital treats takeover as a control loop: signal → framing → audit → proof → build → tests → controlled deployment → measurement → iteration. The signal may be a slow application, a blocked team, an outgoing vendor, recurring bugs, costly technical debt or a roadmap that cannot start.

• Signal: identify why takeover has become necessary now.
• Framing: choose the critical journeys and risks to reduce first.
• Proof: ship a low-risk change that is tested and deployed cleanly.
• Build: progressively take over priority features.
• Measurement: track stability, fix time, incidents and delivery speed.

Should the app be fixed, refactored or rebuilt?

The right decision depends on three criteria: business criticality, technical debt and cost of change. If the application works, supports operations and can be stabilized, progressive takeover is often better than a rebuild. If the architecture blocks every evolution, if data is inconsistent or if security is too fragile, a redesign may become more rational.

Practical rule: do not decide to rebuild before proving what is actually broken. Many web apps look unrecoverable because they are undocumented. Once access, tests and dependencies are clarified, the decision becomes more objective.

Connect the web app to the wider business system

A web app never lives alone. It may connect to an ERP, CRM, marketing site, mobile app, email system, accounting exports or internal automation. The takeover must therefore inspect the full system, not only the code repository. This is the same logic as an ERP recovery or an existing mobile app takeover: secure before accelerating.

The Business software & AI for SMEs hub is the central destination: the goal is not to save code for its own sake, but to take over a tool that runs the business.

Checklist before any modification

• Have critical accesses been recovered and separated by role?
• Do backups exist and has restoration been tested?
• Is there a test or staging environment?
• Are critical dependencies and versions known?
• Is sensitive data identified and protected?
• Are critical business journeys listed?
• Can the first change be deployed and rolled back cleanly?

FAQ

How long does it take to take over an existing web app?

A useful first audit can often be produced within a few days. Full takeover then depends on complexity, available access, data, debt level and production risk.

Should everything be rebuilt?

Not necessarily. A rebuild is justified when debt, security or architecture prevent evolution. But that decision should come from an audit, not from intuition.

What is the first proof to request?

A small correction deployed cleanly, with backup, test, control and rollback possibility. It shows that the team has regained control.

Next step: Say Digital can run a web app takeover diagnostic: access, architecture, risks, debt, test environment, quick wins and prioritized action plan.

Sources and resources

• OWASP — Web Security Testing Guide
• OWASP — Application Security Verification Standard
• NIST — Secure Software Development Framework
• ANSSI — cybersecurity publications
• CNIL — personal data security
• Say Digital — ERP recovery
• Say Digital — existing mobile app takeover

Version française : Reprendre une webapp existante : sécuriser avant de modifier