Software takeover and maintenance: verify control, protect one path, agree the boundary

OutsourcingVN is operated by Netbase JSC, which offers managed delivery, so this checklist comes from a supplier that would like to take over your system. It applies whichever provider you choose, and it draws on a multi-year platform engagement Netbase has run since 2020, a recovery scope and a platform migration.

What this guide covers

• Why does a takeover need its own plan?
• What goes in the takeover inventory?
• How do you protect the critical path first?
• What should the maintenance boundary say?
• What coverage can you expect?
• What does a multi-year engagement look like?
• Worked scenario: the first month of a takeover
• What usually goes wrong?
• Which questions should you ask the incoming provider?
• How this guide is sourced and where it stops
• Common questions
• Start with the current control map

Why does a takeover need its own plan?

Source-code access is not operational control. A repository without its deployment history, secrets, data ownership and the knowledge of who restarts what at month-end is only part of a system. Most takeover problems come from what is missing rather than from the code itself: an account in a departed developer's name, a scheduled job nobody documented, a certificate that expires next month.

A takeover plan makes those gaps visible before the incoming team is responsible for them. It also protects the buyer: if the new arrangement does not work, the same inventory makes the next transition possible. The handover and exit guide covers the conversation with the outgoing team. If the system is still being evaluated before a purchase or investment, run software technical due diligence first.

What goes in the takeover inventory?

Record every asset, who holds it today, how control is verified and what transfer means. An item that cannot be verified is a risk, not an asset.

The data security and compliance guide lists the access questions to settle before anyone is granted production rights.

What should the maintenance boundary say?

A maintenance arrangement fails when either side assumes the other covers something. Write down:

• Systems in scope. Named applications, environments and integrations.
• Coverage days and hours. When requests are worked, and what happens outside that window.
• Request types. Incidents, defects, small changes and security patches, each with its own route.
• Change authority. Who approves a production change, and what acceptance check and rollback it needs; the release readiness checklist lists the evidence.
• Exclusions. Redesign, migration and new capability go to a separate project decision under project delivery, not into support.
• Reporting. What is reported, how often and to whom.
• Exit. Which artefacts and access stay with the buyer at all times.

Netbase also offers dedicated development teams, on-demand support and fully managed delivery as secondary options. Managed Operations is the service route for agreeing this boundary, and the managed software operations scope guide turns the list into a written scope.

What coverage can you expect?

Coverage should be stated, not implied. For Netbase, the Hanoi office works Monday to Saturday, 9:00-18:15 Vietnam time (UTC+7), and support coverage follows those days. Anything beyond that is agreed per engagement and written into the contract before the business relies on it. Design the critical path so that a failure outside coverage lands in a safe state with an alert, rather than waiting for someone to notice. Reliability and incident readiness covers alert routing, runbooks and restore rehearsals.

What does a multi-year engagement look like?

Since 2020 Netbase has worked as offshore development and managing partner on a multi-tenant cloud ERP SaaS for a US client (not named). Phase 1, from 2020 to 2023 and aimed at agency SMEs, covers CRM, real-time messaging, HR, knowledge base, custom fields and workflows, work and project management, and API integrations. The stack includes React and Next.js, Laravel and Strapi, PostgreSQL, MySQL, MariaDB and MongoDB on AWS. The retail phase 2 was planned work when the profile was written and is not presented as delivered.

See the multi-tenant cloud ERP SaaS platform record

A long engagement like this depends on the same discipline as a takeover: a stable review rhythm, written decisions and a system someone else could pick up. Netbase delivery runs with weekly reviews and a named project manager.

Worked scenario: the first month of a takeover

A distributor's order portal was built by a freelancer who has moved on. The portal syncs orders to the warehouse every night.

The domain and the hidden job are typical. Each would have become an outage if found during an incident instead of during week 1.

What usually goes wrong?

• Secrets in a departed developer's account. Signal: a service stops when an old account is closed. Owner: the buyer owner, via rotation in week 1.
• Undocumented scheduled jobs. Signal: a month-end report silently stops. Owner: the incoming team, via the inventory.
• A domain or registrar in a personal account. Signal: nobody can change DNS. Owner: the business sponsor.
• Backups never restored. Signal: a restore fails during an incident. Owner: the incoming team, via a rehearsal.
• Support quietly becoming a rebuild. Signal: "maintenance" tickets that take weeks. Owner: the buyer owner, who moves them into a project.
• A compromise found mid-takeover. Signal: unknown files or redirects. Owner: the security owner, who switches to an investigation-first recovery like the three-phase Magento recovery scope.

Which questions should you ask the incoming provider?

• What will the inventory cover, and how will you verify control? Expect a table like the one above.
• Which journey will you protect first, and how? Look for a baseline, monitoring and a restore rehearsal.
• What are your coverage days and hours? Expect a written window, not "always available".
• Who owns the code, accounts and data? For custom development the client owns the IP created for it; Netbase productized modules and products are licensed, not transferred.
• How will you protect our accounts and data during the takeover? At Netbase, security practices include secure code review and version control, role-based access control, MFA for admin dashboards, contributors under NDA, and NDAs and DPAs on request.
• What happens when the platform itself is at end of life? Look for a migration assessed as a separate project, like Netbase's Netztech Magento 1 to Magento 2 migration, delivered in 35 working days including 11 extensions.

How this guide is sourced and where it stops

This guide draws on Netbase delivery records and company practices approved in the OutsourcingVN claim register: the cloud ERP engagement, the recovery scope, the Netztech migration, support coverage, IP ownership, security practices and the review rhythm. The methodology explains how those records are sourced. It is written for technology and operations leads inheriting a system. Coverage beyond office days, and any response commitment, are agreed per engagement rather than published here.

Start with the current control map

Bring the system, the access you hold, the critical journey and the name of the person who can grant access. Managed Operations covers the maintenance boundary once control is verified, and the handover and exit guide covers the outgoing side.

OutsourcingVN is Netbase's own outsourcing-services platform. Submit a project with your control map, and a person will reply with whether a takeover assessment is feasible before suggesting maintenance.

Related services and solutions