Replace an existing export in small steps
A completed transition plan with identical test data, explicit read permissions and a limited rollback path.
Choose a function with a clear boundary
Start with a concrete outcome, such as a reliable report export. The Strangler Fig pattern describes replacing individual functions while others remain in the existing system. First check whether calls can actually be routed separately and whether both solutions can operate together temporarily.
List callers, interfaces and scheduled background jobs. Record fields, file format, error cases and access rights. Fowler emphasises letting desired outcomes and suitable seams guide modernisation. Do not accept old defects as business requirements without examination.
Example plan for a read-only export
This plan is entirely fictional. A fixed test snapshot contains SR-18 with status approved and 90 minutes, and SR-19 with status draft and 30 minutes. The agreed rule is to export approved entries only. The table describes expected evidence, not executed tests.
Phase | Task | Expected evidence |
|---|---|---|
Baseline | Run the old export on the fixed test snapshot. | 1 data row: |
New implementation | Run the new export with read permissions on the same snapshot. | Again 1 data row: |
Limited switch | Route selected calls to the new implementation; keep the old path available. | Authorised calls return the agreed result; unauthorised calls are rejected. The rollback path has been checked. |
Remove the old exporter | Move remaining callers and background jobs; assign operational ownership. | No dependency on the old exporter remains. Evidence and limits of the rollback path are recorded. |
In this example, writes and authoritative data ownership stay entirely in the old application. The new function receives only the read permissions it needs; the database schema does not change. Compare both exports against the same fixed snapshot. Different moments in changing live data would distort the comparison.
Check the new access path and the return route
Routing does not replace access control. OWASP requires appropriate permission checks on every request. Include direct calls to the new export, rejected access and error messages in the checks.
The return route applies only while the old read path and data format remain compatible. It does not demonstrate database restoration. After the switch, the old exporter can be removed; the rest of the application is still needed to maintain and store data. If separate routing is impossible or the entire old system must be retired soon, the plan needs a different boundary.
Sources
Read more
All articles
Software Development with ASES
Custom software, web and mobile apps