Operating IT Systems You Didn't Build: A Takeover Playbook
Thousands of Vietnamese businesses run systems left behind by former contractors — no documentation, no handover, nobody willing to touch them. Taking those systems over safely demands a disciplined process, not bravado.
In the life of any IT system, the original builders eventually leave: the contract ends, the in-house team disbands, or the outsourcing firm stops supporting it. The business is then left with a hard question — who will operate, maintain and secure a system that nobody in the organisation truly understands?
Taking over the operation of a system built by someone else is one of the hardest jobs in IT. Unlike building from scratch — where every decision is within your control — inheriting a system means inheriting the technical choices, the vulnerabilities and the technical debt you never created. This article lays out the process TechShield uses to take over and run inherited systems safely and under control.
01Why inheriting someone else's system is always risky
Most Vietnamese businesses, especially small and medium ones, don't develop software in-house — they outsource. Systems get built by third-party contractors, software houses, or a handful of freelancers. When the contract ends or staff move on, the system keeps running but the operational knowledge walks out the door with the people who built it.
The problem isn't whether the system runs — it does, sometimes for years. The problem is that when something breaks, nobody knows where to start. Passwords live in the head of a developer who quit, the architecture exists only in someone's memory, and every small change is a gamble because nobody is sure what else it might affect. This is what engineers call a 'black box' — it works, but it can't be understood.
Architecture diagrams, deployment guides and operational runbooks are usually missing or years out of date compared to the system actually running in production.
Old libraries, end-of-life language versions and code patched across multiple contractors make every upgrade a risk of breaking the system.
Systems left unpatched for long periods typically contain publicly disclosed CVEs, misconfigurations, and default accounts that were never changed.
Access rights, API keys and critical credentials are often tied to individuals who have left, creating a real risk of total loss of control in an emergency.
02Stage 1: Discovery and system mapping
The first step in taking over an unfamiliar system is not to fix or upgrade — it is to understand. TechShield begins with a discovery phase in which every digital asset is inventoried and mapped: servers, databases, services, domains, SSL certificates, cloud accounts and external integrations. The goal is to turn the 'black box' into a clear diagram that both the business and the operations team can see.
This process almost always surfaces surprises: a server running with no clear purpose, a database holding customer data that isn't covered by any backup, or a payment service still calling the old contractor's API. Complete mapping is a prerequisite — you cannot safely operate what you haven't fully seen.
Catalogue every server, container, database, domain, certificate and service account — together with its status, owner and business criticality.
Analyse data flows and dependencies between components to reconstruct the real architecture, rather than relying on outdated documentation.
Audit who can reach the system, remove accounts belonging to former staff and contractors, and re-establish least-privilege principles.
Identify every third-party service, API and licence the system depends on — catching the points that could fail unexpectedly early.
03Stage 2: Reconstructing documentation and knowledge transfer
A system with no documentation is a system that cannot be operated sustainably — every incident has to be solved from zero. After discovery, TechShield reconstructs the core operational documentation: architecture diagrams, deployment procedures, incident-handling guides and a configuration catalogue. These become assets owned by the business, not tied to any individual — ensuring the knowledge never disappears again.
When the former contractor or staff can still be reached, TechShield runs structured handover sessions to capture tacit knowledge — the things that were never written down but are critical: why a service was configured in an unusual way, the history of past incidents, or the 'sensitive spots' that should never be touched without fully understanding them.
Rebuild architecture diagrams, deployment procedures, configuration catalogues and dependency maps — stored centrally and kept current with the live system.
Write step-by-step guides for common incident scenarios: system down, disk full, database errors, certificate expiry — so anyone on call can respond.
Conduct interviews and working sessions with the former contractor (while still reachable) to capture tacit knowledge before it disappears for good.
04Stage 3: Establishing monitoring and observability
Inherited systems usually run in the dark — no alerts, no centralised logs, nobody aware of a problem until customers complain. TechShield's next step is to give the system 'eyes and ears': deploy infrastructure monitoring, collect logs centrally, and configure threshold-based alerts for the vital signs.
TechShield deploys the WatchTower monitoring platform to track the health of servers, services and applications in real time. Before anything can be optimised, you need a baseline of the system's normal behaviour — only by knowing what 'normal' looks like can you detect the 'abnormal'. This is the foundation for moving from reactive operations (waiting for incidents) to proactive operations (catching problems before they become disasters).
Track CPU, memory, disk, network and service health in real time, catching problems before they reach end users.
Aggregate logs from every component in one place, enabling fast root-cause tracing instead of digging through scattered servers.
Set up automated alerts via email, Slack or Telegram when metrics cross safe thresholds — so the on-call team knows before the customer does.
Establish a baseline of normal behaviour to distinguish natural fluctuation from genuine signs of an incident or attack.
05Stage 4: Reviewing and hardening security of the inherited system
A system built by someone else and left neglected is an ideal target for attackers: unpatched software, libraries with disclosed CVEs, default accounts and API keys scattered through the source code. TechShield runs a comprehensive security assessment as soon as the architecture is understood — vulnerability scanning, configuration review, and an audit of every credential that exists in the system.
A step often skipped but absolutely critical is rotating every secret: passwords, API keys, certificates and tokens. When you take over a system, you can never be sure who else still holds the old credentials — the contractor, a departed developer, or even credentials that have already leaked. Rotating every secret is the only way to regain real control.
For businesses that process personal data, this is also a legal requirement. Vietnam's Decree 13/2023/ND-CP compels organisations to apply technical measures to protect personal data proactively — you cannot use 'someone else built the system' as an excuse to avoid liability when a breach occurs.
Review all software, libraries and operating systems for disclosed CVEs, and plan patching by risk priority without disrupting service.
Replace all passwords, API keys, certificates and tokens to invalidate any credential the former contractor or an attacker might still hold.
Check firewall rules, permissions, open ports and internet-facing services against hardening standards such as the CIS Benchmarks.
Ensure the system meets Vietnam's personal data protection requirements, with a complete audit trail ready for regulators.
06Stage 5: Steady-state operations — runbooks, SLAs and incident management
Only once a system is understood, documented, closely monitored and hardened is it truly ready for steady-state operations. At this stage, TechShield establishes clear service-level agreements (SLAs): response times, target resolution times, and committed availability tiered by how critical each system is.
Professional operations is not firefighting whenever something breaks — it is a disciplined process: every change goes through change management to avoid risk, every incident is logged and analysed for root cause so it doesn't recur, and every action is traceable. This is the difference between 'the system still runs' and 'the system is being operated'.
Define response and resolution times by priority level, plus committed availability — transparent and measurable every month.
Every change is planned, tested and given a rollback plan, avoiding a situation where one small edit takes down a fragile inherited system.
After each incident, analyse and fix the real cause rather than just restarting — steadily reducing incident frequency over time.
“A system still running doesn't mean it's being operated. Real operations is when you know what's happening before anything breaks.”
07Engagement models and real-world results
TechShield offers three flexible takeover models depending on the business's needs: full takeover (TechShield runs everything), co-operation (working alongside the in-house team with training and knowledge transfer), or phased advisory (supporting only the initial discovery and hardening, then handing back). Whichever the model, the transition phase is always handled carefully so business operations are never disrupted.
A retail chain in Ho Chi Minh City came to TechShield when the contractor that built their POS and inventory-management system shut down, leaving an undocumented system that had gone two years without patching. After 90 days of takeover: stable uptime rose from 97.2% to 99.9%; more than 40 vulnerabilities were patched, including 8 critical ones; over 60 credentials were fully rotated; and mean time to resolve incidents dropped from 'undefined' to under 30 minutes.
“We used to dread every error alert because we didn't know who to call. Now someone understands the system better than the people who built it.”
Key takeaways
- 01Taking over a system someone else built isn't about fixing first — it's about understanding first: discovery, mapping and documentation are mandatory foundations.
- 02Rotating every secret (passwords, API keys, certificates) is the critical step to reclaim control from former contractors and any latent leaks.
- 03Monitoring and centralised logging turn a 'black box' into an observable system, enabling the shift from reactive to proactive operations.
- 04Legal liability under Decree 13/2023 is not waived just because 'someone else built it' — operating safely is also operating in compliance.