Application maintenance and managed operations, agreed in an assessment
Managed Operations keeps a production system maintained and improving under an agreement written after a paid assessment. The assessment defines which systems are covered, what "covered" means, the service levels and how you leave. No response time or service level is published: those numbers go into a contract after the assessment, or they do not exist.
Submit a project Compare engagement modelsReviewed by David Nguyen (CEO) · Updated 6 Oct 2026
What does managed operations cover?
OutsourcingVN is operated by Netbase JSC, and this page describes Netbase's own service. Netbase also offers dedicated development teams, on-demand support and fully managed delivery as secondary options; this service is the entry point to the last of those. It keeps a working system running and improving: corrective work, release management, dependency and security updates, reconciliation between integrated systems, and a queue of small improvements with agreed capacity. It sits after delivery, not instead of it. The full offer list is on the services page.
The service always starts with a paid assessment and onboarding milestone. That milestone has its own deliverable, and you can stop after it with a document you can hand to anyone, including another supplier.
What is it not?
- It is not around-the-clock coverage. Netbase does not publish a 24/7 operations promise.
- It is not a promise about business results. Uptime, revenue, adoption and vendor behaviour depend on things outside delivery control.
- It is not an open-ended arrangement. If the systems, the coverage and the exclusions cannot be written down, there is nothing to agree.
- It is not a rescue. If the system is failing now, a bounded technical audit sprint is the faster and cheaper first move.
Is your system ready for managed operations?
Good fit
- The system is in production and its current state can be inspected during the assessment
- A named owner on your side can approve changes, releases and priorities
- The systems in scope, and the ones explicitly out of scope, can be listed
- You accept that service levels are set in the contract, not taken from a web page
- Continuous improvement capacity is wanted alongside corrective work
- The platform underneath the system is already built
Another route fits better
- Coverage is needed before anyone has been allowed to look at the system
- There is no owner, so every request becomes an escalation with nobody to escalate to
- The expectation is that everything connected to the system is covered by default
- A published coverage window or response time is required before any assessment
- The real need is a new build, which belongs in a delivery project
- The platform itself still needs building; Cloud Platform and DevOps Engineering builds infrastructure as code, CI/CD, inference hosting and cost controls first, then hands over into this service
Compare internal operations, the incumbent maintainer, a specialist support provider and other managed-service suppliers against the same system inventory. Ask each for severity and coverage terms, response and restoration targets, reporting, a change queue, and an exit and handover plan.
The assessment is the entry point
The assessment reads the system as it is: the code and its dependencies, the deployment path, the environments, the integrations, the existing logging and alerting, the backlog of known defects, and the access and credentials that would have to change hands. It records who does what today, including the parts your own team will keep doing.
Its output is a proposed operating agreement, written in enough detail that a contract can be drawn from it. Where the system cannot support a commitment yet, the assessment says so and lists what would have to be built first. An assessment that concludes "not yet, and here is the shortest path to yes" has done its job.
Most Netbase projects are agreed as fixed-scope contracts after discovery, and milestone-based arrangements are also available; engagement models explains how the choice is made.
What the assessment decides
Each item below is agreed during the assessment and written into the contract. None of them is offered as a standing figure here.
The named applications, services, environments and integrations that are covered, and the ones that are not.
The hours and days during which requests are handled, in your time zone and ours, stated as an agreed window rather than a claim of continuous availability.
The severity scale, what each level means in your business, and the response and restoration targets attached to it.
The access, approvals, environments, vendor contacts and decisions you provide, and what happens to a target when one of them is late.
When changes may be deployed, how much notice is given, and who approves a deployment outside the window.
How much improvement capacity the agreement includes each period, how it is prioritized, and what happens to unused capacity.
The work that is outside the agreement, such as new product scope, third-party defects and changes a vendor controls.
What is reported, how often, and to whom, so performance against the agreed targets can be checked rather than asserted.
Notice, handover, documentation, access transfer and data return, agreed at the start rather than negotiated under pressure.
where the system includes one delivered under AI workflow automation, including who owns the evaluation set and the threshold to re-test after a model or prompt change.
How the work is done
-
Assess and onboard
Inspect the system, record the current state, draft the operating agreement, and transfer the access and knowledge the work needs.
-
Agree the terms
Turn the draft into a contract: scope, coverage, service levels, dependencies, windows, change allowance, exclusions, reporting and exit.
-
Run the agreed cycle
Handle corrective work and releases, spend the improvement capacity on the agreed priorities, and record what happened against the targets.
-
Review and adjust
Report on the agreed schedule, review whether the targets still fit the system and the business, and change them by written agreement rather than by habit.
Project teams draw on business analysis, project management, solution architecture, development, QA and UI/UX roles. One Netbase delivery lead owns the plan and reports against it, remote-first from Hanoi. Netbase stays accountable whether the work is done by Netbase staff, approved specialists or disclosed partners. Project delivery describes the governance.
Reporting and exit
Two parts of the agreement protect you more than any number in it.
Reporting exists so that performance is checked against the targets you agreed, on a schedule you agreed, in a format you can take to your own stakeholders. If a target was missed, the report says so. Watch for three signals that the agreement needs revising: corrective work consumes the improvement allowance for two periods running, targets are met only because incidents were downgraded, or the same dependency on your side is repeatedly late. Each belongs in the report with the owner who acts.
Exit is written at the start. It states the notice period, what is handed over, how access and data are returned, and how long Netbase supports a transition to your team or another supplier. An operations agreement you cannot leave is not an agreement worth signing.
Security, ownership and AI-assisted delivery
Operations work means standing access to systems and data, so the handling is agreed before any of it is granted. Netbase JSC holds ISO 27001 certification for information security management, and Netbase JSC holds a SOC 2 Type II attestation; both describe Netbase's own practice and never extend to your system or hosting. Netbase engineers and operates cloud environments on AWS, Google Cloud, DigitalOcean and Cloudflare, choosing the provider per workload, so a takeover is not limited to one vendor's platform. Secure code review and version control, role-based access control, multi-factor authentication for admin dashboards and contributors under NDA are standard practice, and NDAs and data processing agreements are available on request.
For custom development, the intellectual property created for you belongs to you. Netbase's own productized modules, where the system uses them, are licensed rather than transferred. Netbase engineers use AI tools to speed up tasks such as reviewing changes, drafting tests and writing documentation; every change that ships is reviewed and owned by a named engineer.
Frequently asked questions
There is no published response time. The severity scale and its response and restoration targets are agreed in the assessment and written into your contract, because they depend on the system, the coverage window and the dependencies you can commit to.
Not as a published offer. The Hanoi office works Monday to Saturday, 9:00-18:15 Vietnam time (UTC+7), and support coverage follows those days. Any other coverage window is agreed per engagement, and only a window Netbase can staff and evidence is worth signing.
That is decided in the assessment, based on what the system already has and what it needs. This page does not name a stack, because the honest answer depends on your environment.
Yes. The assessment exists to find out what taking it over would involve before either side commits.
Yes. The assessment is a milestone with its own deliverable, and your own team can run the operating agreement it produces.
No. Targets are agreed for the things delivery controls. Results that depend on your users, your vendors or your market are not promised.
What comes before a takeover, and what has Netbase inherited?
The service follows either a delivered project, most often one scoped as custom product engineering, or an audit such as a technical audit sprint, which produces the evidence the assessment would otherwise gather from scratch. The software takeover and maintenance guide walks through that path; the legacy system risk assessment, legacy data migration planning, data security and handover and exit guides cover the questions an inherited system raises. Before you hand a system over, the technical due diligence guide sets the evidence to gather, the managed operations scope guide defines the service boundary, reliability and incident readiness covers on-call and recovery, and the release readiness checklist governs each change.
The nearest published record of inherited-system work is the compromised Magento store recovery: for an existing client store, Netbase scoped a three-phase recovery covering investigation and malware scanning, cleaning and core-file restoration, then repair, security patches and hardening, typically 6 to 13 days depending on the damage, with no recovery guarantee. No ongoing operations record is published yet. Every record is on the Work page, and the methodology page sets their rules.
Ready to scope the assessment?
Submit a project brief naming the systems, who owns them today and what a bad week currently looks like. If the system is still being designed, or the question is whether AI belongs in it, start with an AI workflow blueprint instead. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.