Legacy Software Modernisation: A Practical Implementation Guide

If you are running a legacy system that your business depends on, you have probably considered replacing it. And you have almost certainly discovered that the cost, risk, and disruption of a full replacement are difficult to justify. A 2024 survey by Standish Group found that 66% of large-scale software replacement projects experience significant cost overruns, timeline delays, or outright failure. For mid-market organisations, the numbers are not much better.

The good news is that you do not need to replace your legacy software to give your team a modern way to work with it. Regardless of whether your legacy platform is a thirty-year-old ERP, a custom-built database application from the 1990s, or an established system with no vendor-supported API, the fundamental approach is the same: build an interface layer that sits on top of your existing system.

Over the course of delivering modernisation projects across dozens of different legacy platforms, we have observed a consistent six-phase implementation pattern. It works for AS/400 green-screen systems, for FoxPro database applications, for early-2000s .NET WinForms apps, for heavily customised ERPs, and for in-house-built systems that nobody on the current team fully understands.

This guide walks through that pattern in detail. By the end, you will know exactly what steps to take, what to watch out for, how to structure your team, and how to plan your timeline. The guidance is technology-agnostic — the principles apply whether you are modernising Dynamics NAV, Sage 200, a custom PHP application, or a legacy Java desktop client.

Legacy Modernisation Follows a Pattern

Modernising a legacy application might feel unique to your situation. Your legacy codebase is idiosyncratic. Your business processes are specific to your industry. Your data model has accumulated twenty years of organic growth. And yet the implementation pattern is remarkably consistent across organisations.

Every legacy modernisation project follows the same six phases:

1. Discovery — understand what you have
2. API or data layer — build the connection
3. Adapter layer — isolate the legacy integration
4. Frontend build — create the modern interface
5. Testing with real data — validate against live data
6. Go-live and iterate — phased rollout and improvement

This guide covers each phase in detail, with practical advice for teams undertaking legacy software modernisation for the first time.

Phase 1: Discovery — Understand the Legacy System

The discovery phase is where most projects succeed or fail. Rushing past discovery to start building is the single most common mistake in legacy modernisation. You cannot design an interface layer for a system you do not fully understand, and legacy systems are almost never as well understood as their users believe.

In our experience, every legacy application harbours undocumented behaviours: business rules embedded in stored procedures, validation logic hidden in triggers, data transformations applied by the application layer that are invisible at the database level. A thorough discovery phase uncovers these before they become project-blocking surprises.

What to inventory during discovery

The legacy platform itself. What technology is the existing software built on? Is it a commercial off-the-shelf product, a heavily customised instance of one, or a fully bespoke application? What version and patch level are you on? Is the vendor still supporting it, or are you running unsupported? What is the deployment architecture (on-premise, hosted, cloud)? Who maintains it currently, and what is their availability for questions?

The data model. Where does the data live? In a relational database (SQL Server, Oracle, PostgreSQL, MySQL), a flat-file system, or a proprietary data store? Can you read it directly via ODBC/JDBC, or does it require intermediate tools? What is the schema and how well is it documented? In our experience, documentation is almost always out of date — you should plan to do your own schema discovery. Are there any large tables, unusual data types, or computed columns that will need special handling?

API or integration surface. Does the legacy system expose an API? If so, what protocol (REST, SOAP, OData, custom TCP, COM/DCOM)? What authentication mechanism does it use (OAuth 2.0, NTLM, basic auth, certificates)? What endpoints are available and what CRUD operations do they support? Are there rate limits, concurrency limits, or licensing restrictions on API usage? If no API exists, what database-level access do you have? Can you create a read replica without impacting production performance?

Business processes. How do people actually use the legacy system today? Watch your team working. Do not rely on process documents or interviews alone — people describe what they think they do, not what they actually do. Observe where they click, where they pause, where they tab out of the application to open Excel, where they write down a reference number on a sticky note because the system does not make it easy to copy. These friction points are your prioritisation guide for the new interface. Rank them by frequency and impact: a twelve-second annoyance that happens two hundred times a day is a more valuable target than a five-minute frustration that happens once a week.

Data quality. Legacy systems accumulate data quality issues over time. Orphaned foreign keys, inconsistent date formatting, free-text fields that store structured data, duplicate customer records, missing mandatory fields. These will surface when you try to present the data in a modern interface, where inconsistencies are immediately visible in a way they are not in a green-screen terminal or a cluttered legacy grid. Identify the worst data quality hotspots during discovery so you can plan how to handle them in the interface layer — whether that means data cleaning, graceful degradation, or surfacing warnings to users.

Security and permissions model. How does the legacy system control access? Does it have role-based security, or is it all-or-nothing? Are permissions enforced at the database level or the application level? The new interface needs to respect the same access controls, and understanding the existing model will inform how you build authentication and authorisation into the adapter layer.

Discovery deliverables

At the end of discovery, you should have a clear picture of the legacy system's architecture, a documented inventory of available integration points (API endpoints, database tables, or middleware), a prioritised list of user pain points ranked by frequency and impact, and a clear scope definition for what the new interface will cover and what it will explicitly exclude. Without these deliverables, do not proceed to build.

Phase 2: API or Data Layer — Build the Connection

Once you understand the legacy system, the next step is to establish a reliable, secure connection to read and write data. How you approach this depends entirely on what the legacy application exposes. There are four common scenarios, and your discovery phase will tell you which one applies.

Scenario A: The legacy system has a REST API

This is the simplest case. If your existing software exposes a REST, OData, or GraphQL API, you can connect to it directly. Modern ERP platforms like Dynamics 365 Business Central, Sage 200, SAP Business One, and NetSuite all offer REST APIs. Even older platforms like OrderWise, Epicor, and IFS provide API access of varying maturity.

In this scenario, authentication is handled via standard protocols (OAuth 2.0, API keys, or basic auth over HTTPS). Your interface layer talks to the API in real time, and the legacy system remains the sole system of record. Be aware of rate limits: many commercial ERP APIs cap requests per minute or per hour, and exceeding the limit will cause your interface to return errors until the window resets. Plan your caching strategy accordingly.

Scenario B: The legacy system has a SOAP or proprietary API

Many legacy applications from the 1990s and 2000s expose SOAP web services or proprietary network protocols. These can still work, but you need an intermediary. Build a thin middleware service that translates between the legacy protocol and modern REST. Your frontend never touches SOAP directly. The middleware handles the protocol translation, XML-to-JSON conversion, and any complex authentication handshakes. Your frontend talks clean REST to the middleware.

This approach adds some development overhead (typically 1–2 weeks for a straightforward SOAP service) but is a well-understood pattern. The key risk is that SOAP services are often undocumented and may have subtle behaviours that only surface under specific conditions. Budget extra time for exploratory testing.

Scenario C: No API exists — database-level access

This is more common than you might think. Many legacy applications, particularly custom-built or heavily customised ones, have no API at all. In this case, you have two options, depending on whether you need read-only access or write-back:

Read from the database directly. If the legacy database schema is stable and you have read-only access, you can query it directly for display purposes. This works well for dashboards, reporting, and read-only customer portals. Create a read replica of the database to avoid impacting the legacy system's performance — you do not want your new interface causing query contention that slows down the production application. Use connection pooling and query timeouts to protect against runaway queries.

Write via a bridge. Writing data back into a legacy system without an API is harder. Options include writing to staging tables that the legacy application picks up on a scheduled basis, using file-based integration (the legacy app polls a directory for CSV or XML files), or building a custom connector using whatever extension mechanism the legacy system offers (CLR trigger, COM plugin, or stored procedure). Each approach introduces latency between the write and its visibility in the legacy system, so set expectations accordingly.

Scenario D: Middleware or integration platform

If your organisation already uses an integration platform (Azure Logic Apps, Boomi, MuleSoft, Workato, or a custom ESB), you can leverage it as the data layer. The middleware already knows how to connect to the legacy system; your interface layer connects to the middleware. This can accelerate development significantly, but it adds a dependency on the middleware platform's reliability, performance, and cost structure. Ensure the middleware SLA aligns with your interface layer's uptime requirements.

Phase 3: Adapter Layer — Isolate the Legacy Integration

The adapter layer is the most important architectural decision in any legacy modernisation project. It is a dedicated service that sits between your new frontend and the legacy system, isolating all legacy-specific integration code in a single, well-defined place. Think of it as a translation layer: the legacy system speaks its own language (proprietary API, arcane database schema, idiosyncratic data formats), and the adapter layer translates that into clean, modern REST endpoints that your frontend can consume without knowing anything about the legacy system's internals.

Here is the architecture:

Legacy System
  (DB / SOAP / proprietary API)
     │
     │  Direct DB query / API call / middleware
     │
     ▼
Adapter Layer (isolated service)
  · Connection management & auth
  · Request/response mapping
  · Data transformation (legacy → modern)
  · Caching (Redis or in-memory)
  · Error normalisation
  · Idempotency for write operations
  · Circuit breaker for resilience
  · Audit logging
     │
     │  Clean REST API (internal, not public)
     │
     ▼
Application Layer (Next.js / React / TypeScript)
  · Server-side rendering
  · React Server Components
  · TypeScript, strict mode
  · Role-based routing
     │
     ├── Staff Operations Portal
     ├── Customer Self-Service Portal
     └── Management Dashboard

Why the adapter layer matters

Without a dedicated adapter layer, legacy integration code ends up scattered across your application like weeds. Every page, every component, every API route has its own copy of the legacy connection logic. When the legacy system changes (and it will — a vendor update, a schema change, a new authentication requirement), you have to find and update every single reference. This is exactly the problem that made the original legacy system hard to maintain in the first place, and you would be recreating it in your new system.

With a properly designed adapter layer:

• If the legacy API endpoint URL or response format changes, only the adapter layer needs updating. Your frontend does not change at all
• If you ever decide to replace the legacy system with a new one, only the adapter layer needs rewriting. Your frontend applications continue to work unchanged because they talk to the adapter, not to the legacy system directly
• Caching, error handling, retry logic, rate-limit management, and circuit-breaking are all centralised in one service
• Data transformation between legacy formats (proprietary date formats, legacy character encodings, non-normalised structures) and modern JSON happens in one place
• Audit logging for all data access through the new interface is consistent and complete

The adapter layer exposes a clean REST API to your frontend. The frontend never talks to the legacy system directly, never queries the legacy database, never handles legacy authentication. This decoupling is what makes legacy modernisation both safe and sustainable over the long term.

What the adapter layer handles

Connection management: Authenticating against the legacy system using whatever mechanism it requires (OAuth, NTLM, basic auth, certificate, database login), managing session tokens and their refresh cycles, handling reconnection gracefully if the connection drops, and pooling connections where appropriate to avoid hammering the legacy system with repeated authentication handshakes.

Data transformation: Legacy systems often use date formats that predate ISO 8601 (DDMMYY, Julian dates, fiscal periods), number formats with comma as decimal separator, character encodings that are not UTF-8, and data structures that embed multiple values in a single field. The adapter layer normalises everything to consistent, modern formats before passing data to the frontend. This transformation is invisible to users — they simply see dates formatted correctly and numbers that make sense.

Caching: Frequently accessed data that changes infrequently (customer lists, product catalogues, pricing tables, reference data) should be cached to reduce load on the legacy system and improve frontend response times. A Redis cache or in-memory cache with configurable TTL works well. Cache invalidation is critical: the adapter layer should either set conservative TTLs or listen for change notifications from the legacy system to evict stale entries.

Error normalisation: Legacy systems return errors in maddeningly inconsistent ways. A database deadlock might surface as error code -2147217900 with a message in all capitals. A validation failure might return a SOAP fault with a nested stack trace. An API timeout might simply hang until the HTTP client gives up. The adapter layer catches all errors, interprets them, and returns a consistent error structure to the frontend with a human-readable message, a machine-readable error code, and an HTTP status code that the frontend can handle appropriately.

Idempotency: Network failures happen. Users double-click. Browser tabs get refreshed mid-operation. Write operations should be idempotent to prevent duplicate transactions if a request is retried. The adapter layer generates or accepts an idempotency key for each write operation, tracks completed operations, and returns the cached result for duplicate requests rather than re-executing the operation against the legacy system.

Circuit breaker: If the legacy system becomes slow or unresponsive, the adapter layer should fail fast rather than queueing requests that will eventually time out. A circuit breaker pattern monitors failure rates: after a configurable threshold of failures, the circuit opens and subsequent requests fail immediately without touching the legacy system. After a recovery timeout, the circuit allows a test request through. If it succeeds, the circuit closes and normal operation resumes. This prevents cascading failures from overwhelming an already-strained legacy system.

Audit logging: Every read and write operation passing through the adapter layer should be logged with the user identity, timestamp, operation type, and result. This provides an audit trail that the legacy system may not offer, and it is invaluable for debugging issues after go-live.

Phase 4: Frontend Build — Role-Based, Task-Oriented Interfaces

With the data connection and adapter layer in place, you can build the modern frontend. The technology stack we use and recommend is React with Next.js and TypeScript. This combination gives you server-side rendering for fast initial page loads, React Server Components for efficient data fetching, type safety that catches integration errors at compile time rather than runtime, and a mature component ecosystem that supports complex enterprise interfaces. TypeScript is particularly valuable in legacy modernisation because the data structures coming from the legacy system are often complex and under-documented — strong typing makes the integration points explicit and testable.

Design principles for the frontend

Role-based views. Different teams need different views of the same data. A warehouse operator needs a pick list with bin locations and barcode scanning. A customer service representative needs order history, shipping status, and a timeline of customer interactions. A finance manager needs invoice ageing, payment reconciliation, and credit limit monitoring. A production manager needs job status, machine utilisation, and material availability. Build separate views for each role, even if they read from the same underlying data sources. A role-based approach reduces on-screen clutter, improves task focus, and makes each user feel like the system was built for their specific job.

Task-oriented workflows. Legacy systems are almost always organised around data entities: customers, orders, invoices, stock items. Each entity has its own screen or menu option. But your team does not think in terms of entities; they think in terms of tasks. "I need to check whether a customer's order has shipped" is a task, not a customer screen or an order screen. "I need to raise a credit note" crosses multiple entities (customer, order, invoice, accounting). Design each workflow to complete the task from start to finish without forcing the user to navigate between screens. Common task-oriented workflows include "check order status," "raise a credit note," "schedule a delivery," "approve a purchase order," "transfer stock between locations," and "onboard a new customer." Each task should take no more than a few clicks.

Minimised training. A modern interface should be intuitive enough that a new user can be productive within their first hour. This is the opposite of most legacy systems, which require weeks of classroom training and months of on-the-job experience to navigate efficiently. Use familiar UI patterns (search bars, filters, sortable columns, card layouts, slide-out panels), clear labelling in plain language (not legacy terminology like "F02" or "transaction code 472"), inline validation that tells users what they did wrong and how to fix it, and contextual help that explains each page's purpose in one sentence. Every minute a user spends learning your interface is a minute they are not doing their job.

Responsive and accessible. The frontend must work on desktop, tablet, and mobile without losing functionality. This means responsive layouts, touch-friendly controls, and performance that works on slower connections. It must also meet WCAG 2.2 AA accessibility standards, covering screen reader compatibility, keyboard navigation, colour contrast, and focus management. Legacy systems almost never achieve this, and a modernisation project is a rare opportunity to fix accessibility without the constraints of the legacy UI framework.

Performance as a feature. Legacy system users are accustomed to slowness. A modern interface should delight them with speed. Server-side rendering, incremental static regeneration for reference data, optimistic UI updates for common write operations, and lazy loading for secondary content all contribute to a perception of speed that builds trust and adoption.

Typical frontend modules

• Staff operations portal: Order management and processing, stock lookup with live availability, customer management with full interaction history, task queues with priority and assignment, notification centre for alerts and approvals, reporting views for common operational reports
• Customer self-service portal: Order tracking with live status updates, invoice and statement download, document library (delivery notes, certificates), address and contact management, live chat or ticketing integration, product catalogue with pricing
• Management dashboard: Real-time KPIs and trend charts, revenue tracking with drill-down, operational metrics (order backlog, stock turns, on-time delivery), exception reporting (credit limits exceeded, stock below reorder, overdue orders), export to PDF and CSV
• Specialist and mobile interfaces: Warehouse scanning and put-away workflows, field service with job allocation and completion, goods receipt with PO matching, delivery confirmation with proof-of-delivery capture

Phase 5: Testing with Real Data

Testing against synthetic data will not catch the real issues. You must test your interface layer against live legacy data before going into production. This is where most integration problems surface, and it is where projects that skimped on discovery pay the price.

A legacy system with ten years of production data contains edge cases that no test data set will replicate: null values in fields that were historically mandatory, date entries from the Y2K era in non-standard formats, customer records that violate referential integrity due to long-ago manual imports, and business logic that has accumulated exceptions and overrides over time. Your testing must account for all of these.

What to test

Read operations against real data volume. Your legacy system has years of accumulated data. Test queries at scale to verify that the adapter layer handles pagination, filtering, sorting, and search efficiently. A query that takes 200ms on a development database with 100 rows might take 10 seconds against production data with 2 million rows. Test with production-scale data volumes and identify slow queries early. Add database indexes, query optimisation, or caching where needed.

Write operations end to end. Create, update, and delete records through the interface layer and verify the results are correctly reflected in the legacy system and any downstream processes that depend on it. This is especially important for write-back scenarios where the legacy system enforces business logic, validation rules, workflow state machines, or trigger-based processes that your adapter layer might not fully replicate. A write that succeeds at the database level but fails a legacy validation rule is a silent data integrity failure.

Error handling and edge cases. What happens when the legacy system rejects a write due to a validation rule you did not know about? When the API returns an unexpected HTTP status code? When the database connection drops mid-transaction? When the legacy system is running its nightly batch job and performance degrades by an order of magnitude? When a user enters a value that the legacy system stores differently (a date format, a currency amount with four decimal places, a postcode with an unusual format)? Your testing must cover these scenarios, and the error messages presented to users must be clear, specific, and actionable.

Performance under concurrent load. How does the end-to-end system perform when ten, twenty, or fifty users are active simultaneously? The adapter layer, the network connection, and the legacy system itself all need to handle the aggregated load. Identify bottlenecks before go-live. Common issues include the legacy system's database not being tuned for the query patterns the new interface generates, API rate limits being hit under concurrent usage, and the adapter layer not pooling connections efficiently.

Data integrity verification. Run automated comparison queries that cross-reference data returned by the new interface against data queried directly from the legacy system. Every discrepancy should be investigated and resolved. Even small differences in rounding, date formatting, or null handling can undermine user trust in the new interface. Pay particular attention to calculated fields: if the legacy system computed a value differently than your adapter layer, reconciliation will reveal it.

Authentication and authorisation. Verify that each user role can access only the data and operations they are permitted to see and perform. Test that unauthenticated access is correctly rejected. Test session expiry and re-authentication flows. Test what happens when a user's permissions change in the legacy system.

User acceptance testing

Once technical testing is complete, invite a small group of real users to try the interface in a controlled setting. Watch them work. Do not guide them or explain the interface. Note where they hesitate, where they make mistakes, where they look confused, and where they express frustration. These observations are more valuable than any checklist or scripted test case. The users will find workflow problems that your development team never anticipated because they approach the system with different mental models.

Collect feedback systematically: what worked well, what was confusing, what is missing, and what broke. Prioritise fixes before rolling out more broadly. UAT is not a pass-fail gate; it is a discovery process that improves the interface before wide exposure.

Phase 6: Go-Live and Iterate

Legacy modernisation does not end at go-live. The best approach is a phased rollout with real user feedback driving continuous improvement. Unlike a big-bang replacement where everything must work perfectly on day one, an interface layer can be rolled out incrementally, de-risking each step before moving to the next.

Phased rollout strategy

Pilot group (Week 1–2). Launch with a small group of 3–5 power users who understand the legacy system deeply and can provide informed, constructive feedback. These users will tolerate rough edges better than the general user base, and their feedback will be more specific and actionable. Run the new interface in parallel with the legacy system so they can compare results, verify data consistency, and fall back to the old interface if they encounter a blocker. Collect feedback daily during this phase.

Department rollout (Week 3–4). Expand to a full department or team. Monitor usage metrics actively: daily active users, pages viewed per session, error rates, average response times, support ticket volume. This is where you will discover edge cases that did not surface during the pilot: users who interact with the system differently than the power users, data that follows patterns you have not seen before, and workflows that cross departmental boundaries. Keep the parallel run active so users can fall back if needed.

Full rollout (Week 5–6). Once the department rollout is stable (low error rate, positive user feedback, no unresolved critical issues), expand to the rest of the organisation. Retire access to the legacy interface for the covered workflows, but keep the legacy system accessible for administrative tasks, reporting, and edge-case processes that the new interface does not cover. Communicate the cutover timeline clearly and provide a support channel for users who encounter issues.

Collecting and acting on feedback

Feedback collection should be structured, not ad hoc. Use in-app feedback mechanisms that capture the user's context automatically (which page they were on, what action they were performing, any error state). Schedule regular feedback sessions with user representatives from each role. Track requests by category: bugs (the interface does something wrong), missing features (the interface does not cover a workflow the user needs), and usability improvements (the interface works but could be smoother). Each category needs a different response: bugs are urgent, missing features are prioritised by frequency and impact, and usability improvements are valuable but should not block the rollout.

Iterate in short, visible cycles. Every two weeks, ship a set of improvements based on the feedback you have collected. Communicate what changed in a release note visible within the application. This visible responsiveness builds user trust and drives adoption. A modernisation project that stops evolving at go-live will eventually be perceived by its users as just another legacy system — frozen, unresponsive, and frustrating. Continuous improvement is not optional; it is what distinguishes a modern interface from a legacy one.

Timeline and Team Requirements

A legacy modernisation project of moderate scope (one legacy system, two role-based portals, core data entities) typically requires the following:

Timeline estimate

These timelines assume a dedicated core team working on a single legacy system with a clearly scoped set of workflows. More complex scenarios will extend the timeline:

• Multiple legacy systems that need to be presented as a unified interface: add 4–8 weeks for the additional data layer and adapter work
• No existing API (database-level access only): add 2–4 weeks for the data layer, depending on schema complexity
• Heavily customised legacy system with undocumented modifications: add 1–2 weeks to discovery and 2–4 weeks to the adapter layer
• Real-time data synchronisation requirements (bidirectional sync with near-zero latency): add 2–4 weeks for change tracking and conflict resolution
• Complex data transformation (legacy data that requires significant cleaning or restructuring): add 1–3 weeks per major data domain

Team requirements

For the core delivery team (dedicated, full-time):

• 1–2 frontend developers with React, Next.js, and TypeScript expertise — building the user interfaces, implementing role-based views, and ensuring accessibility and performance
• 1 backend/integration developer — building the adapter layer, implementing data connections, managing authentication, and handling data transformation and caching
• 1 designer/UX specialist — conducting user research, designing role-based workflows, creating wireframes and prototypes, and establishing the design system and component library
• 1 project manager or product owner — managing backlog prioritisation, stakeholder communication, timeline tracking, budget management, and risk identification

From your side (the legacy system owner and domain experts):

• 1 subject matter expert who knows the legacy system and business processes intimately — this is the single most critical role on your side of the project
• 1 IT contact who can provide system access, credentials, database connection details, and infrastructure support for staging environments
• Access to a non-production environment or database read replica for development and testing
• Executive sponsorship with authority to resolve cross-departmental blockers, approve scope decisions, and drive user adoption during rollout

The subject matter expert is the most critical role on your side of the project. They need to be available for the duration of the build, not just for a kick-off meeting and a sign-off call. Projects where the SME is part-time, distracted, or unavailable tend to produce interfaces that look right but miss important business logic, validation rules, or edge cases. If you cannot commit a knowledgeable SME for at least 10–15 hours per week throughout the project, you should delay starting until you can.

Frequently Asked Questions

1. Can we modernise a legacy system that no longer has vendor support?

Yes, and this is one of the most common scenarios we encounter. When a legacy system is no longer supported by its vendor, the risks of modifying it increase significantly (no security patches, no compatibility testing, no vendor help desk). Interface layer modernisation becomes even more compelling in this situation because you leave the unsupported system completely untouched — no modifications, no risk of destabilising it, no voiding of whatever residual support remains. You give your team a modern way to interact with the system's data while the legacy application continues running exactly as it always has. This can buy you three to five additional years of productive life from the existing software, giving you time to plan and budget for a longer-term replacement at your own pace rather than under crisis conditions.

2. What happens if the legacy system goes down?

The interface layer depends on the legacy system for live data. If the legacy system is unavailable, the interface cannot display current data or process new transactions. However, the adapter layer should handle this situation gracefully: showing clear, user-friendly error states that explain the system is temporarily unavailable (not broken), serving cached reference data where possible (product catalogues, customer lists, pricing tables that do not change minute to minute), and providing a mechanism for users to be notified when the system is available again. The legacy system's own availability SLA determines the interface's availability, so your operational monitoring and incident response processes need to cover both systems. Consider this an incentive to improve the legacy system's uptime too.

3. Do we need to modify the legacy system at all?

No. The entire premise of interface-layer modernisation is that you do not touch the legacy system. You connect to it via its existing API, database, or middleware interfaces. No modifications. No risk to its upgrade path or vendor support agreement. No additional licensing fees from the legacy vendor. No need for the legacy vendor's involvement or approval. This is the fundamental advantage over approaches that involve customising, extending, or adding modules to the legacy application itself. Those approaches carry risk; interface-layer modernisation does not.

4. How do we handle data that exists only in the legacy system's proprietary format?

Data transformation is the responsibility of the adapter layer. If the legacy system stores dates in a proprietary format (DDMMYY, Julian dates, fiscal periods with year-month codes), or uses internal integer IDs instead of human-readable references, or stores monetary values without an explicit currency indicator, or uses character encodings that are not UTF-8, the adapter layer transforms this data into standard, portable formats before passing it to the frontend. The legacy system keeps its internal format completely unchanged. The adapter layer handles all translation transparently. Users see properly formatted dates, human-readable names, and correctly formatted numbers without ever knowing that a transformation occurred.

5. Can we build the interface layer in phases, or does it need to be all at once?

Phased delivery is strongly recommended and is the standard approach for any project of moderate complexity. Start with read-only views of the most frequently accessed and highest-value data: order status, stock levels, customer information, invoice history. These are quick to deliver and immediately demonstrate value to users. Add write-back capabilities for the most common transactions (order creation or amendment, stock adjustments, customer details updates) in a later phase as the integration patterns are proven. Add additional roles, portals, and workflow coverage incrementally as you go. This approach de-risks the project at every step and delivers visible value early. A read-only dashboard can be live within two to three weeks, even if the full write-back interface takes several months. Do not fall into the trap of waiting until everything is perfect before releasing anything.

6. How does the new interface handle security and user permissions?

Security is enforced at the adapter layer, not in the frontend. The adapter layer authenticates against the legacy system and enforces the same permissions that exist in the legacy application. If the legacy system has its own role-based permission model, the adapter layer respects it. If the legacy system has no permission model (all users have the same access), the adapter layer implements its own role-based access control, with roles defined during the discovery phase. Authentication should use your existing corporate identity provider (Microsoft Entra ID, Okta, Azure AD, or similar) so users log in with their existing credentials and do not need a separate account or password for the new interface. Single sign-on (SSO) is a significant quality-of-life improvement that reduces password fatigue and support requests for forgotten credentials.

---