Application maintenance and managed operations, agreed in an assessment
Netbase also offers dedicated development teams, on-demand support and fully managed delivery as secondary options. This page describes the entry point to the last of those: an assessment that defines exactly which systems are covered, what "covered" means, and what both sides owe each other. Nothing on this page states a coverage window, a response time or a service level, because none is published. Those numbers are written into a contract after the assessment, or they do not exist.
Submit a project Compare engagement modelsReviewed by David (CEO) · Updated 23 Sep 2026
What this service is
Maintenance and managed operations keep a system that already works 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 this service is not
- It is not around-the-clock coverage. Netbase does not publish a 24/7 operations promise, and this page does not create one.
- It is not a promise about your business results. Uptime, revenue, adoption and vendor behaviour depend on things outside delivery control, and no outcome of that kind is guaranteed.
- It is not an open-ended retainer with an undefined scope. 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.
Good fit and poor fit
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
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 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. That answer is a legitimate result: an assessment that concludes "not yet, and here is the shortest path to yes" has done its job.
Commercial terms follow the same rule as the rest of the portfolio. Most Netbase projects are agreed as fixed-scope contracts after discovery, and milestone-based arrangements are also available; the terms belong in the proposal, not on this page. 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.
Work is staffed with the roles the scope needs, typically drawn from business analysis, project management, solution architecture, development, QA and UI/UX. One Netbase delivery lead owns the plan and reports against it, remote-first from Hanoi, in increments with regular reviews. 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.
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. 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 coverage window is agreed per engagement, and a window that Netbase can staff and evidence is the only kind 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, and that is the common case. The assessment exists precisely to find out what taking it over would involve before either side commits.
Yes. The assessment is a milestone with its own deliverable. Many buyers take the operating agreement and run it with their own team.
No. Targets are agreed for the things delivery controls. Results that depend on your users, your vendors or your market are not promised.
What normally comes first
This service has a natural predecessor. It 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 have to gather from scratch. If neither has happened, the assessment does that work itself and takes longer.
Anonymized delivery records are on the work page, and the rules that govern what a record may claim are on the methodology page. No operations record is published yet, so this page claims the offer and its entry point, nothing more.
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.