Modernising legacy applications does not mean rewriting the entire system at once. For many businesses, the better first question is which function needs to change, what can keep running for now, and how an order stays correct during the transition. DAXS would therefore map an existing Windows or Linux application by its data, interfaces and vendor approvals before deciding on a new user interface, API or platform.
Moving the existing VM can separate the operating system from its hardware, but it does not yet modernise the application itself. Acceptance testing for a VMware/Proxmox migration is a separate step. This article concerns longer-term changes to functions and integrations while the business continues operating.
Describe the existing system, then draw a boundary
An inventory needs more than a list of server names. Each service needs an application record covering its owner, user groups, Windows or Linux version, database and drivers, batch jobs, file shares, printers, identity source, inbound and outbound interfaces, and maintenance and licensing contracts. Less visible paths matter especially: a nightly CSV export to accounting, a service account with an expiring password, or a desktop client whose version is tied to the server.
For proprietary software, the vendor determines which guest operating systems, database versions, drivers and virtualisation environments it supports. Direct writes to its database may appear to be an easy integration, yet can violate business rules, warranty conditions and later updates. DAXS would first assess a documented API, an approved export or a vendor SDK. Without any supported integration point, incremental replacement may be technically or contractually unsuitable; a different decision is then needed with the vendor.
An example: renew order status, retain the order-processing core
Suppose an internal order-management system has a Windows application service, an SQL database and a nightly export. Customers frequently ask about order status, while the old core reliably processes orders and invoices. The first new function could be a read-only status view supplied through an approved interface. The order-processing core and its database remain authoritative initially.
An integration layer translates old identifiers and status values into a documented new model. This is known as an adapter or anti-corruption layer. It is not a magic API in front of an uncontrolled database: per-order permissions, authentication, input validation, rate limits, logging and response times need fresh assessment. OWASP identifies object-level authorisation and authentication among the central API risks. Even a read-only status query must not expose other customers’ orders.
Only once the read function is stable should a bounded write process follow, such as entering one order type. Data ownership now becomes critical: while the old core is authoritative, the new interface must not silently create a second, independent truth. For every record, establish which system may write, how requests are recognised unambiguously, and how failed attempts, delayed messages and corrections are reconciled. Having both systems write simultaneously is not a transition plan without a business conflict model.
Four stages with a measurable stopping point
| Stage | Change | Evidence required before the next stage |
|---|---|---|
| 1. Secure the existing system | Record dependencies, contracts, data flows and recoverable backups | Restore the application and database in a test network; reconcile a sample order with the business |
| 2. Separate reads | Use an approved export/API for the new status view | Measure status accuracy, viewing rights, update delay and load against the legacy system |
| 3. Move one write case | Route only one order type through the new interface; define data ownership | Record each order exactly once, reconcile documents and corrections, rehearse rollback |
| 4. Retire the legacy part | Switch off only after proving transfer of functions and data | No unresolved hidden callers, export/retention duties or vendor dependencies |
Replacing individual functions in stages resembles the Strangler Fig pattern. It does not fit everywhere: if requests cannot be redirected, the vendor blocks every interface, or the entire small system is easily replaced, an adapter may cost more effort than it delivers in value. The transition layer itself needs monitoring, capacity and an operator; it must not become a new single point of failure.
Define rollback before the first production write
For a read-only status view, rollback is often simple: disable the new view, continue using the order core and investigate the cause. After the first write to a new database, switching a proxy back is insufficient. New orders, cancellations and documents must be returned to the old system or reconciled by the business. Each change therefore needs a final reconciled data state, a clear write stop, export/import procedures, named responsibilities and a rehearsal. Microsoft’s incremental-replacement documentation explicitly warns that rollback becomes harder once old data objects have been removed.
The old environment must also remain in scope during parallel operation. If its operating system or application no longer receives security updates, restrict and monitor the affected services, network paths and access, and set an exit date. A new API in front does not eliminate vulnerabilities in the old core. Whether isolation is sufficient depends on the specific risk and available vendor measures.
Assess effort and limits honestly
A three- or five-year comparison includes at least inventory, vendor and licensing clarification, adapter development, data mapping, security assessment, test data, business acceptance, parallel operation, monitoring and later decommissioning. New operating-system or database licences and training for people operating both environments may also be needed. Parallel operation is an explicit cost, not a free intermediate stage. An incremental solution is worthwhile only when avoided operational risks and new functions justify the actual effort; no universal savings percentage follows.
DAXS would choose a small, visible first boundary with the business, such as the example status view, and assess correct data, response time, supportability and restore. The next decision is which further function actually needs a separate service. For the technical foundation of an existing VM, Proxmox in business provides the infrastructure context; operating API access predictably adds the later interface-management perspective. To prepare a specific application record, contact DAXS via Contact.
Sources: Microsoft Azure Architecture Center: Strangler Fig pattern · Microsoft: Anti-Corruption Layer pattern · OWASP: API Security Top 10.
