Archaeology
Recording what the system actually does — including what is documented nowhere.
Solution
We modernize systems that still hold up the operation and therefore cannot be switched off. The work is progressive: old and new coexist while the value migrates, in stages that can be reversed.
Recording what the system actually does — including what is documented nowhere.
What breaks the operation if it fails, what is peripheral and what is no longer used at all.
A sequence of deliveries with value of their own, each with a way back.
A layer that lets old and new operate together through the transition.
Transfer with validation, total checks and a period comparing both sides.
We rewrite what pays back; what works and bothers nobody can stay.
A safety net proving the old behaviour was preserved where it should be.
The legacy is switched off only after the new system holds the operation, with a plan for retaining history.
The second column is the one almost nobody publishes. It exists because a scope with a declared limit is the only honest way to agree on price and deadline.
If the system works, blocks no business decision and costs little to maintain, modernizing is spending on aesthetics. If the company will change its business model next year, modernizing now means rebuilding something that will be thrown away. And if nobody on the client side has the authority to decide business rules, the project stalls — modernization is 40% archaeology and 60% decision.
The first stages usually deliver value in weeks; full replacement is measured in months and sometimes years. Be wary of anyone who promises a fixed schedule before the assessment: until the survey ends, nobody knows what is in there.
Size and age of the legacy system.
Whether documentation and people who know the rules still exist.
How tightly the modules are coupled.
Quality and volume of the historical data.
How much downtime the operation tolerates.
How many integrations depend on the legacy.
A solution is not a separate box: it is the same services applied to one specific problem.
A solution is not bought from a catalogue. It starts with an assessment of the real process, and only then becomes scope, schedule and proposal.
It can, and it is the most common way to fail. A total rewrite has a long schedule with no interim delivery, while the operation keeps running on the old system — which needs maintenance meanwhile. We work in stages that carry value of their own.
The plan is designed not to. Where a window is unavoidable, it is agreed, short, and has a rollback procedure tested beforehand.
It migrates with validation: total checks, sampling and a period in which both sides are compared. What does not migrate stays available for consultation for as long as the company must keep it.
Yes, and it is the most common case. The assessment exists precisely for that: understanding what is there before committing to any schedule.
It happens, and that is why the plan has stages with completion criteria. When the assessment changes, the plan changes and the conversation is open — rather than the schedule slipping in silence.
Legacy Modernization
The first conversation and the preliminary assessment cost nothing. Only then come the scope and the proposal.