Software maintenance (MA/SLA) and legacy modernization
We keep systems running under a maintenance agreement with agreed response times, and modernise the ones that have become hard to change, step by step and without stopping the business. We support systems we built and systems built by other vendors.
Services in this pillar
Each service has its own page with scope, approach and buyer questions.
Maintenance & Support
Monitoring, security patching, incident response and small changes for live systems, including ones we did not build.
Application Modernization
Modernising a legacy system in stages while the business keeps running on it.
Data Migration
Moving data from a legacy system to a new one, with mapping, cleansing, reconciliation and a tested rollback.
Dedicated Development Team
A MERCIL engineering team assigned to your product long term, working to your priorities with its own delivery practice.
Choosing what to do with an ageing system
Before modernising a system, find out what is wrong with it. Slow, risky changes point to missing tests and a tangled architecture. Trouble connecting to other systems points to the interfaces. If nobody understands the system, the gap is documentation and knowledge. A system that runs correctly and cheaply but looks old may be best left as it is.
When change is justified, the options are to put a clean interface in front of the old system, to move functions to new code one at a time, or to replace it. The public debt management system that replaced the PDMO's SAP-based GFMIS-TR is an example of a replacement. Support runs alongside all three: monitoring, incident response within agreed times, security and dependency updates, and time each month for fixing the causes of repeat incidents.
What organisations ask about modernisation and support
Should we rewrite the system or modernise it in stages?
Usually in stages. A full rewrite means running two systems, freezing new features and reaching feature parity before the budget runs out. A rewrite makes sense when the business process has changed a great deal or the old platform can no longer be kept secure. We assess the system first and recommend one route, with our reasons.
Can you support a system you did not build?
Yes. We start with a review of the code, the deployment process, dependencies and monitoring, and report what we find. The first weeks are slower while we learn the system, and the estimate includes that time.
How do you price ongoing support?
Against a defined scope: which systems are covered, during which hours, the response and resolution targets for each severity, and how many hours a month go to preventive work. You know what is included, and work outside the scope is quoted separately.
Can you migrate our data off a legacy system?
Yes. Most of the effort goes into mapping and cleaning the data, and into reconciliation: showing that record counts and totals match between old and new, accounting for every exception, and rehearsing both the cutover and the rollback before the real run.
Next step
Start with a conversation
Tell us about the problem you are trying to solve. A senior person reads every inquiry and replies with our view of fit, scope and cost, including when another option would suit you better.