Studying and modernizing an old application: approach and limits

1. Permission and law first

Studying an application by reverse engineering should only be done on software you own, whose license allows it, or that you are authorized to work on. License agreements and local law can restrict it. If you're unsure, get legal advice before you start. This post describes an engineering approach for applications you have the right to work on.

2. Observe the behavior

• Document the screen flows and what each screen does.
• Record the network requests of the app running on your own device with a proxy tool: addresses, request and response samples, the authentication scheme.
• Inspect the database schema, file formats and logs.
• If you have the source, read it and recover the missing documentation from it.

3. Extract the contract

From your observations, write the contract the application exposes: the list of endpoints, the input and output schema of each, the data model and the business rules (calculations, state transitions, permission rules). This document is the real source for the modernization, and it is often documentation the old system never had.

4. Write characterization tests

Pin down the old system's current behavior as tests: for a given input, what output does it give? These tests should run against both the old and the new system. Decide deliberately whether each oddity in the old system is a real business rule or a bug.

5. Move piece by piece

Instead of replacing everything at once, build the new system next to the old one and shift functions to the new side one at a time (the strangler fig pattern). The tests must pass at every step and you should be able to go back to the old one if needed. That keeps risk small and users don't see downtime.

6. Document and hand over

Turn the contract, the decisions and the known oddities into documentation. The lasting gain of a modernization is that the system becomes understandable and testable.