OutsourcingVN is operated by Netbase JSC, which scopes and runs accountable project teams. This is the assessment chapter of the legacy system modernization guide, and the commercial route is a technical audit sprint: a bounded, paid piece of work with a named mission, a timebox and an explicit end.
An assessment that only produces a proposal is a sales document
The free assessment is the most expensive thing on the market. It is paid for in scope: the supplier looks for long enough to write a convincing proposal for the work it already sells, and stops. Nothing it found is written down in a form you can hand to a second supplier, challenge, or act on yourself.
A bounded piece of paid work behaves differently. You own the output, you can take it elsewhere, and the recommendation can honestly be "do nothing yet" without the supplier losing the engagement — because the engagement was the assessment. That is the only arrangement in which a finding you did not want to hear reaches you intact.
So buy it as its own scope, with its own acceptance criteria, before any build is agreed. Most Netbase projects are fixed-scope contracts agreed after discovery, and an assessment is what makes that later scope honest.
What to assess, and what evidence proves it
A finding is only worth what its evidence is worth. The right-hand column is what to insist on.
| What to assess | What proves it |
|---|---|
| Inventory of systems and interfaces | A list reconciled against running processes, deployment configuration and integration logs, not memory |
| Where the business rules live | Each rule quoted from the code, stored procedure, spreadsheet or interview note holding it |
| Build and release | A build reproduced from the repository by someone who never built it before |
| Dependencies and versions | A generated list with the version and support position of each |
| Out-of-support components | The supplier's own end-of-support statement for that named version |
| Access and credentials | An account list per system with named owners, and a recorded sign-in for each route you keep |
| Data profile | Row counts, growth, personal-data locations and known defects, produced by running queries |
| Operational behaviour | Incident records, monitoring output and on-call history over a period, not a summary |
| Knowledge concentration | Who can change what, and what stops when each of them is unavailable |
| Exit position | Each item needed to run the system alone, marked held or not held |
| Legal and contractual position | The contracts, licences and IP terms governing code and data, read rather than recalled |
Where the domain rules actually live
The most valuable output of an assessment is usually a map of where the rules are, because that determines whether the system can be replaced at all.
Expect them in at least four places: the application code, stored procedures and triggers in the database, scheduled jobs nobody lists as part of the system, and a spreadsheet on somebody's drive that the whole month-end depends on. Expect a fifth: one person's head, applied by hand when the system produces something wrong.
Each location costs something different to move. Rules in code can be read. Rules in the database are frequently missed by teams who assume the application owns the logic. Rules in a spreadsheet are invisible until its owner is on leave. Rules in a head do not survive a rewrite, and they are the usual reason a replacement that passed testing is rejected by the people who have to use it.
Dependencies, access, and who can still get in
Produce the dependency list from the system, not the documentation: runtime, framework, libraries, database engine, operating system and the external services the system calls. Mark each supported, out of support or unknown, and treat unknown as a finding. An out-of-support component is not automatically urgent, but it is always a decision, and it becomes urgent the first time it blocks a security fix.
Then check access, the item most often discovered too late. Who holds credentials to the servers, the database, the repository, the domain registrar and the cloud account? Is any of it held only by a former supplier or a departed employee? Can you sign in today, or only believe you could? Record a successful sign-in for every route you must keep, because a route nobody has used in two years often no longer works. Handling of what the assessment sees is agreed before it starts: 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, as data security and compliance describes.
The operational picture, and the data at headline level
Ask what breaks, how often, and who gets called. The evidence is incident records, monitoring output and the on-call history over a real period — not an opinion collected in a meeting, because the people asked stopped noticing the failures they work around every week. Look for the manual step that keeps the system alive: the restart somebody performs on Monday mornings, the report regenerated by hand when it comes out wrong.
The data profile belongs here at headline level only: entity counts, growth, where personal data sits, and the defects already known. That is enough to size the risk. Full profiling is separate work, described in legacy data migration planning, and does not belong in an assessment timebox.
The people the system depends on
Write down who can change what, and what stops if each of them is unavailable. If one name appears against most of the system, that is the highest-consequence finding in the report, and it is not a criticism of that person — it is a description of your exposure.
Ask the connected questions: is that person employed by you or by a supplier, is anything written down, and would they be available to a project that replaces the system they built? The last decides whether modernization can be staged with their help or reconstructed without it.
The exit position
The exit position lists everything the organisation would need to run and change this system without its current supplier: source code and its full history, build and deployment configuration, infrastructure definitions, credentials and account ownership, third-party licences, data and its documented schema, runbooks, and the contractual right to all of it.
Mark each item held or not held, today, with evidence. This is not an accusation against an incumbent; it is a statement of where you stand, and it is worth doing while the relationship is good. IP ownership in software outsourcing covers the contractual side, handover and exit the practical transfer, and supplier due diligence the questions that stop the next contract recreating the position.
How to run the assessment
-
Write the question and the boundary
The decision the assessment feeds, the systems in scope, what is excluded, the timebox and the date the decision is needed.
-
Arrange access before the clock starts
Read access to repositories, a non-production environment, logs, dashboards and documents. Late access is the commonest cause of a thin report.
-
Inventory first, opinions later
Establish what exists and what talks to what, from the running systems rather than the diagram on the wall.
-
Read the code and run the queries
Locate the rules, generate the dependency list, profile the data at headline level, reproduce a build.
-
Interview the people who hold it up
After the evidence, so the conversation is about specifics rather than impressions.
-
Rank by consequence
Separate what is dangerous now from what is merely untidy, and give every accepted risk a named owner and a review date.
-
Write the exit position,
item by item, held or not held.
-
Review the findings with the people who must act,
and record the decision taken on each.
Delivery is remote-first from Hanoi in Agile increments with weekly reviews, using AI-assisted engineering under human review; tools help read unfamiliar code, but every finding is reproduced and owned by a named engineer. The team draws on business analysis, project management, solution architecture, development, QA and UI/UX roles, and Netbase stays accountable whether the work is done by Netbase staff, approved specialists or disclosed partners.
What the assessment hands over
Three things, and you should refuse the engagement without them.
A written finding per item, with its evidence. Enough that a competent third party can check it without repeating the work, and that you can act on it if you never speak to the supplier again.
A ranked risk list. Ordered by consequence to the business, reasoning visible, each risk carrying an owner and a decision: fix, mitigate, or accept with a review date.
A scoped recommendation you can accept or decline. What to do, in what order, with the shape of each piece of work — written so that declining it is a normal outcome. Where the recommendation is to replace something, replace or refactor legacy software sets out that choice; where it is to proceed in stages, incremental modernization without a rewrite sets out how, and legacy application modernization is the build route. For custom development the intellectual property created for you belongs to you, and the report is yours to take anywhere.
Plan the next step for your project
What an assessment cannot tell you
An assessment is a snapshot taken with the access granted, in the time agreed. A clean finding means the checks that were run found nothing then: absence of evidence is not evidence of absence, and the report should say so in those words. Anything found outside the mission is logged and reported, not investigated inside the timebox.
It is also not a formal attestation. Netbase is an engineering supplier, not an accredited assessor, so an assessment cannot be presented to a customer, insurer or regulator as compliance against a named standard. This page publishes no durations or counts of ours.
The nearest delivery record is long-running platform work, not a catalogue of assessments. Since 2020 Netbase has worked as offshore development and managing partner on a multi-tenant cloud ERP SaaS platform for a client that is not named; its first phase, from 2020 to 2023, covered CRM, real-time messaging, HR, a knowledge base, custom fields and workflows, work and project management and API integrations, on a stack that includes React and Next.js, Laravel and Strapi, PostgreSQL, MySQL, MariaDB and MongoDB on AWS. A later retail phase was planned work when that profile was written and is not presented as delivered. The cloud ERP platform record is anonymised.
Common questions
They can, and the report should say so in its method section. Where independence has to be visible to a board, use someone with no stake in the recommendation.
Long enough to reproduce a build, run the queries and read the incident history; short enough to be a timebox. A schedule stretching past a few weeks usually means two missions wearing one name.
No. It is the normal starting position, and it is what makes the inventory step the largest part of the work. Documentation is an output, not a prerequisite.
No. An assessment you can decline is the only kind worth paying for, and the ranked risk list keeps its value whichever supplier does the work.
Find out what you actually have
Bring the system, the decision waiting on it, and the date that decision is due. For how we source the claims on this page, see our methodology. When you are ready, submit a project. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.
Related services and solutions
Technical audit sprint: a bounded evidence pack, not an opinion
A technical audit sprint is a short project with one named mission, a fixed timebox, an agreed ceiling on effort and an explicit end. It answers a question you can state in a sentence: whether a codebase can carry two more years of growth, why a release keeps failing, how exposed an application is. The output is an evidence pack and a decision, not a retainer and not an opinion delivered in a meeting.
Learn More