Important rules are not always written in a specification. They may be embedded in an old process, a daily workaround or an experienced user’s knowledge.

The proposed discovery work brings together representative journeys, exceptions, interfaces and reference data. With your business stakeholders, we distinguish behaviours to preserve from defects and rules that no longer serve a purpose.

1. Understand the dependencies

Identify critical functions, exchanges between applications and business owners. Use this map to choose an intervention that fits operational constraints.

2. Select an initial scope

Choose a function whose value and boundaries are clear enough to assess. Define what changes, the cases to validate and the conditions for release.

3. Prepare coexistence

A progressive migration can leave some functions in the monolith while moving others into new components. Interfaces and ownership of data must be explicit. The Strangler Fig pattern describes this type of incremental replacement. Microsoft reference

4. Validate in a parallel test environment

The migration plan includes a test environment separate from production, where new journeys can be checked against expected behaviour. Its scope, access and datasets are defined during discovery. Sensitive information must be protected and, where necessary, replaced with suitable test data.

Comparisons use concrete examples: calculations, permissions, generated documents, integrations and background jobs. Differences are reviewed with business stakeholders. Emails, payments and other external actions are disabled or directed to test systems.

5. Release a validated scope

Each production release includes an acceptance decision, appropriate monitoring and a planned response to problems. A rollback must account for data written after the switch; its feasibility is checked before the change.

6. Retire unused components

Old components are removed after checking remaining usage, dependencies and applicable retention requirements. Documentation is updated so the team can continue evolving the application.

Your business representatives validate expected behaviour. The technical lead prepares transition decisions, the project manager coordinates work and dependencies, and QA checks the agreed journeys.

Your Lugher helps communicate context and decisions between your organisation and the engineering team in India. Meeting rhythms and validation arrangements are agreed for the project.

Discovery can produce a system map, a list of sensitive business rules, an initial migration scope and a test plan. Assumptions, coexistence costs and unresolved questions are made visible before committing to further work.

Keeping the monolith and improving its internal structure may also be appropriate. The target architecture depends on usage and the team’s ability to operate it.

Tell us about your application, its constraints and the changes you need. Together, we can identify a concrete starting point.

Let’s talk →