Legacy ERP systems in the public sector have become bottlenecks for development and adaptation to modern requirements. Any change, integration with new government services, or functional update takes 3–6 months and often requires downtime. This leads to departments creating their own “shadow” IT solutions to bypass limitations, and the launch of new electronic services or adaptation to legislative changes occurs significantly slower than among competitors.
As an integration solutions architect with 15 years of experience, I believe that instead of trying to revive a monolith or replace it with a single “big bang,” the path to successful digital transformation lies in phased decomposition of legacy ERP. This means extracting individual functions into microservices with API access, allowing for system modernization without business interruption and with minimal risks.
Architectural reasons and organizational challenges
The problem with legacy ERP is not just outdated code or technologies; it is deeply integrated into organizational processes. ERP systems created decades ago were designed as monolithic data and business logic repositories. They did not anticipate flexible integration with dozens of external services, mobile applications, or rapid adaptation to changing regulatory requirements. Every change in one module can have unpredictable consequences for others, turning development into a constant risk.
For example, in a government agency processing citizen appeals, the ERP might contain information about applicants, financial operations, and HR records. If a new API is needed for data verification to integrate with a government e-services portal (like Diia), it could affect dozens of internal processes that no one has documented. In practice, the largest cloud costs arise not from expensive services but from resources forgotten 3-4 months after launch, and in the context of ERP, these are forgotten test environments that run for years.
Typical mistake: “Big bang” instead of evolution
The most common and costly mistake in legacy system migration projects, especially in the public sector, is attempting to replace the entire system in one project. This applies not only to ERP but also to Enterprise Content Management (ECM) or Document Management Systems (DMS). The idea of replacing everything at once seems logical on paper, but in practice, it leads to high-risk projects that last for years, exceed budgets multiple times, and often end in failure or freezing.
The reason is simple: a monolithic system has thousands of implicit dependencies that cannot be identified during the planning phase. Attempting to rewrite or replace everything simultaneously means stopping or paralyzing business processes for an indefinite period. The correct path is phased migration. It involves selecting one functional area or business process, extracting it into a new system, running the legacy and new systems in parallel, and then gradually switching users over. This allows for risk control, quick results, and learning at each stage.
ERP decomposition: the path to flexibility
Using a typical scenario in a central executive body with regional departments that processes citizen appeals and conducts interagency interaction, we can see how decomposition works. Their document flow operates through a legacy ECM with limited mobile support, and the requirements for Complex Information Security Systems (КСЗІ) for processing restricted information are becoming increasingly stringent. Integration with the Diia e-services portal and the e-Court system (еСуд) is important.
Instead of replacing the entire ERP, we focus on extracting individual functional blocks. For example, the citizen appeal processing module can be moved to a new low-code BPM platform, such as Scriptum (a low-code BPM platform on UnityBase from InBase), built on the open-source UnityBase platform (developed by InBase). This allows for rapid creation of flexible workflows for processing appeals, integrating them with Diia via standardized APIs, and providing mobile access.
This approach enables the development of new microservices and functional modules that can run in parallel with the legacy system. It eliminates the problem of long development cycles and dependency on the monolith, allowing for quick launch of new digital services. In practice, Softline teams, specializing in system integration, have already integrated Megapolis.DocNet (an electronic document management system from InBase) with government registries and electronic court systems, ensuring compliance with КСЗІ. This not only speeds up appeal processing but also allows for necessary certification for state information systems.
Risks and limitations: when decomposition is not a panacea
While phased decomposition is the most effective approach, it is not without risks. Firstly, if the legacy ERP architecture is so convoluted that clear functional blocks cannot be identified, decomposition attempts can turn into a “tangled mess” that takes more time and resources than a complete replacement. Secondly, if the organization is not ready for parallel operation of two systems (legacy and new) during the transition period, it can lead to chaos and user resistance. Do not start a project without a clear change management plan and communication with end-users. ECM migration projects almost never fail due to data; they fail because new approval routes prove unsuitable for real-world daily exceptions.
Consistent decomposition of legacy ERP transforms migration from a high-risk operation into a manageable process. It allows for launching new functions without downtime of the monolithic system, gradually modernizing infrastructure and business processes without stopping operations. Before launching a tender for a complete ERP replacement, audit key business processes and identify the 2-3 most critical ones that can be moved to separate, flexible systems. 80% of future problems are visible there, and it costs you nothing.