First step
Audit before responsibilitySoftware takeover and recovery
Take over existing software without inheriting hidden risk
FRAI audits, stabilizes and operates business software built by another developer or supplier. We establish control of the code, hosting, data, integrations, credentials, deployment and recovery path before accepting ongoing responsibility.
Live system
No uncontrolled production changeDecision
Keep only what the evidence supportsOwnership
Client-controlled and exit-ready01 — The situation
The software still matters. Its technical ownership no longer works.
A takeover is for a live or near-production system the business still needs, but no reliable team can safely change, recover and operate.
01
The previous supplier is leaving
The repository may exist while production access, deployment knowledge, credentials or integrations remain with the old team.
02
Every change feels dangerous
The application still works, but nobody is certain which version is live, whether recovery works or what an update could break.
03
Knowledge depends on one person
Business rules live in memory, messages and manual workarounds instead of an operating baseline the company controls.
04
The project needs a new technical owner
The objective is not one emergency fix. It is a controlled transfer to software that can be understood, changed and operated.
02 — Readiness check
How much control does your company have today?
Eight focused questions identify whether the immediate issue is access recovery, a takeover audit or urgent stabilization.
Takeover readiness · two minutes
No answers are sent or stored unless you choose to include them in an enquiry.
Current control01 / 08
03 — Before the supplier changes
Secure the assets the business cannot afford to lose
A transition becomes harder when access is requested after the old relationship has ended. Map what the company controls, what is shared and what still depends on the previous team.
Source and delivery
- Repository administration and source archives
- Current production revision and release history
- Build, CI/CD, package registries and signing keys
Infrastructure and identity
- Cloud, server, hosting and billing accounts
- Domains, DNS, certificates and service accounts
- Monitoring, logs, secrets and error tracking
Data and recovery
- Databases, storage and export paths
- Backup location, retention and encryption
- Restore procedure and last known test status
Integrations and rights
- APIs, webhooks, automations and account owners
- Licences, subscriptions and supplier contacts
- Documentation, known risks and intellectual-property terms
04 — The FRAI Takeover Standard
Responsibility is accepted through evidence, not assumption
A takeover is complete only when the agreed gates have passed or the remaining exceptions are documented and accepted.
01Gate 1
Ownership and access are mapped
The repository, infrastructure, domains, data, accounts and authority to act have named owners.
Gate 1
Ownership and access are mapped
The repository, infrastructure, domains, data, accounts and authority to act have named owners.Pass evidence
A written ownership and access inventory with gaps, priorities and revocation actions.No-go condition
No uncontrolled production change while material ownership, authority or rollback access is unknown.02Gate 2
The system can be reproduced and recovered
The production revision, dependencies, configuration, build path and recovery status are known.
Gate 2
The system can be reproduced and recovered
The production revision, dependencies, configuration, build path and recovery status are known.Pass evidence
A reproducibility and recovery finding recorded as proven, partially proven, untested or blocked.No-go condition
A file labelled backup is not recovery evidence until the restore path is understood and, where agreed, tested.03Gate 3
Immediate operational risk is stabilized
Critical incidents, data exposure, secrets, integrations and visibility gaps are contained or prioritized.
Gate 3
Immediate operational risk is stabilized
Critical incidents, data exposure, secrets, integrations and visibility gaps are contained or prioritized.Pass evidence
A risk register and stabilization plan with critical actions assigned and tracked.No-go condition
Feature work does not outrank unresolved critical risk unless the consequence is documented and accepted.04Gate 4
A safe change can be demonstrated
Development, review, validation, deployment and rollback follow an agreed workflow.
Gate 4
A safe change can be demonstrated
Development, review, validation, deployment and rollback follow an agreed workflow.Pass evidence
One controlled change with stakeholder validation and deployment evidence.No-go condition
The takeover is not complete merely because an engineer can read the code.05Gate 5
Managed responsibility is accepted
Operating scope, owners, coverage, recovery commitments, reporting and exit conditions are written down.
Gate 5
Managed responsibility is accepted
Operating scope, owners, coverage, recovery commitments, reporting and exit conditions are written down.Pass evidence
An approved operating scope with inclusions, exclusions, service targets and transition terms.No-go condition
Coverage, response and recovery commitments are never implied; they exist only in the applicable agreement.05 — The decision pack
Useful even when FRAI is not the next provider
The audit connects technical evidence to the decision the business must make. It is not a generic list of code-style comments.
- 01
Control inventory for repositories, infrastructure, domains, data, credentials and third parties
- 02
System, environment, data and critical-integration map
- 03
Build and deployment reproducibility finding
- 04
Backup and recovery-status finding
- 05
Prioritized risk register tied to business impact
- 06
Maintain, stabilize, modernize, migrate, rebuild, replace or retire recommendation
- 07
Ninety-day control plan and priced next-stage proposal
06 — Possible outcomes
Keep the value. Change only what the evidence justifies.
FRAI does not rewrite software to create work, and it does not preserve unsafe code to avoid a difficult decision.
01
Maintain
Document the baseline and move into an agreed maintenance model.
02
Stabilize
Correct access, deployment, monitoring, recovery or integration risk before feature work.
03
Modernize
Replace selected dependencies or components while retaining useful business logic.
04
Migrate
Move the application, database or infrastructure with validation and a rollback path.
05
Focused rebuild
Retain recoverable data and rules while rebuilding the component that cannot be operated safely.
06
Replace or retire
Choose a standard product, smaller system or retirement when custom recovery is not responsible.
07 — Client fit
A takeover needs authority, a business owner and a real operating need
Company size matters less than the importance of the software and whether control can be established.
Usually a good fit
- The software is live or close to production and supports a meaningful business workflow
- The current provider is leaving, unavailable or no longer the right technical owner
- The company can obtain the rights and access needed for review
- A business owner can validate priorities and critical workflows
- The objective is controlled responsibility rather than the cheapest emergency patch
May not be a fit
- There is no authorization or legal right to access or modify the software
- Feature work must begin before material risks can be understood
- A guaranteed recovery or zero-downtime promise is required before audit
- The request expects unstated 24/7 coverage or unlimited maintenance
- The technology or required operating coverage falls outside FRAI's supported scope
08 — Investment and timing
Know the next commitment before more code is written
The first paid stage establishes the evidence required for a responsible scope, price and operating decision.
Software Takeover Audit
€1,500 + VATThree-day technical assessment · final decision pack within five business daysOne focused application and primary repository, one production environment, the primary database and up to three critical integrations.
Paid in full before work begins. The delivery window starts after the agreed access is complete.
One clear commercial rule
The audit is always credited when FRAI delivers the recommended next stage.
The €1,500 is deducted once from the final invoice for implementation work on the same audited system when that work is accepted within 60 days. The credit applies to FRAI professional fees, is capped at the implementation value, cannot be exchanged for cash and does not apply to third-party costs or recurring services.
€3,000 project → €1,500 remains€5,000 project → €3,500 remains€20,000 project → €18,500 remains
No production change, remediation or bug fixing
No penetration test, certification or legal review
No exhaustive review of additional repositories or environments
Active incidents and access recovery require a separately agreed scope
09 — After acceptance
A precise operational baseline, with no implied coverage
Deployment and monitoring can start small. Broader responsibility is priced only after the application and its operating risk are understood.
Managed deployment and monitoringFrom €225/month + VAT
For one already-stabilized production application. This is an operational baseline, not complete managed responsibility.
Included
- Operation of an existing automated deployment path
- Continuous availability and endpoint monitoring
- Basic certificate and domain-expiry monitoring
- A documented high-level approach to data access, backup responsibility, retention and recovery
- Verification that the agreed backup mechanism is configured and reporting as expected where FRAI controls or supports it
- Alert collection and a concise monthly status summary
Not included at this level
- New backup infrastructure, storage, restoration testing or recovery work unless explicitly included
- Incident investigation, remediation and code maintenance
- Hosting, cloud, licences and monitoring-platform costs
- Out-of-hours human response or guaranteed resolution times
Recurring services are paid monthly in advance. Automated checks may run continuously; human response follows the coverage written into the agreement. FRAI takes operational responsibility for the data safeguards explicitly included in that agreement. Backup infrastructure, restore testing, releases, maintenance, integrations, incident handling, RPO and RTO beyond the entry boundary are scoped after takeover acceptance.
10 — Ownership and exit
A successful takeover should make the next takeover easier
The operating model reduces dependence on personal accounts and undocumented knowledge.
01
Code and licences
Ownership, reuse rights and applicable third-party licences are agreed before work starts.
02
Data
Business data remains the client's, with export, retention and deletion responsibilities made explicit.
03
Accounts
Critical services should use client-controlled organizational accounts wherever practical.
04
Documentation
Architecture, environments, deployment, integrations, recovery and common runbook actions stay current.
05
Transition
The exit path includes access, exports, known risks and the material an authorized successor needs.
11 — Frequently asked questions
Questions before responsibility changes hands
01Can FRAI take over software built by another company?
Yes, when the client has the necessary rights and access. FRAI starts by reviewing the repository, production environment, data, integrations, credentials, deployment, recovery status, documentation and current risk.
02Should we end the current supplier relationship first?
Usually not abruptly. First identify which accounts, access and knowledge still depend on the supplier. Contractual or legal questions should be reviewed by qualified counsel.
03Can FRAI take over software with no documentation?
Potentially. Missing documentation increases reconstruction work, but the audit tests what can be reproduced and records the unknowns before responsibility is considered.
04What if the repository does not build?
That becomes a material finding. FRAI identifies whether configuration, dependencies, environment knowledge, source files or production mismatch are responsible and recommends the safest next stage.
05Can the application stay live during takeover?
Often, but this cannot be promised before review. Stability, data exposure, backup status, deployment risk and rollback options must be understood first.
06Do you always rewrite legacy software?
No. FRAI keeps what is valuable and supportable. The responsible outcome may be maintenance, stabilization, selective modernization, migration, focused rebuild, replacement or retirement.
07Can you take over without source-code access?
Limited access recovery, data extraction or replacement planning may be possible, but normal takeover and maintenance usually require authorized source access. FRAI never bypasses access controls.
08How long does the takeover audit take?
The standard audit uses a three-business-day technical assessment and delivers the final decision pack within five business days after complete access and kickoff.
09How does the audit credit work?
When FRAI performs implementation work on the same audited system and that work is accepted within 60 days, the €1,500 audit fee is deducted once from the final implementation invoice, subject to the published credit terms.
10Does FRAI provide 24/7 support or an SLA?
Only when the applicable agreement explicitly includes it. Automated monitoring, human coverage, response targets, RPO, RTO and emergency procedures are separate commitments.
11Can another provider take over from FRAI later?
Yes, subject to the contract and third-party licences. FRAI aims to keep repositories, documentation, access inventory, exports and known risks clear enough for an authorized successor.
12What if the software cannot be recovered safely?
FRAI documents why and proposes the least risky alternative: retain the data, rebuild a critical workflow, migrate to a standard product, replace the application in stages or retire it.
12 — Related routes
Takeover transfers responsibility. These services support the next decision.
01
Software audit
A detailed review of code, infrastructure, data, deployment, integrations, recovery and risk.
Explore the service02Legacy modernization
Modernize, migrate or rebuild selected parts after the system is understood.
Explore the service03Custom software maintenance
Corrective, preventive and evolutionary work for software FRAI can operate safely.
Explore the service04Managed software operations
The broader model for hosting, monitoring, maintaining and improving business software.
Explore the service13 — Assess the takeover
Bring the system, the access you have and the risk you cannot accept
FRAI will identify whether the next step is access recovery, the fixed takeover audit, controlled stabilization or another route.
No production change is made before authority, scope and risk are agreed in writing.