Document Management · 07.09.2026

Integration bus for EDM: connecting legacy registers to modern interfaces

Modernizing IT infrastructure without full system replacement: how an integration layer connects legacy registers with modern EDM interfaces while maintaining data integrity.

Large-scale modernization of government and corporate IT infrastructures requires a rapid transition from monolithic legacy systems to flexible integration layers without interrupting critical processes. CTOs and IT architects constantly face the challenge of connecting outdated, isolated databases with modern web-based electronic document management (EDM) interfaces. Attempts to connect new portals directly to old tables often lead to data inconsistency, security vulnerabilities, and prolonged downtime during migration.

Legacy registers usually lack flexible APIs for real-time operations, and their data storage logic is incompatible with modern web services. This forces developers to create complex and unstable integration "bridges" instead of a unified bus. However, completely replacing a functioning system is an expensive and risky step. Businesses need a balance that allows for the continuity of business processes while providing users with a modern document management experience.

The trap of full replacement: why rewriting from scratch leads to architectural collapse

When the need arises to implement a modern EDM, the first reaction is often a radical decision to completely replace the old system. However, in engineering practice, the "rip and replace" strategy is considered a last resort with an extremely high level of risk.

Full replacement of large transactional systems or registers is accompanied by massive capital investment and the threat of operational disruption. Historical data accumulated over decades contains specific relationships and hidden business logic that cannot be quickly replicated. Attempting to migrate everything at once often leads to a loss of data integrity.

Using integration layers allows these risks to be avoided. Creating an abstract intermediate layer instead of a full replacement reduces development costs and associated risks significantly. This allows for the gradual modernization of interfaces while ensuring infrastructure stability. It is important to understand that the integration layer itself does not automatically fix the quality and semantics of data in legacy registers—it only provides reliable transport, format translation, and the preservation of historical relationships.

Anatomy of an integration layer: how an API Wrapper saves legacy registers

To connect an old database to a modern EDM interface, architects use the API Wrapper pattern. Instead of allowing external services to execute SQL queries directly against legacy register tables, an abstract software layer is deployed. It transforms outdated interaction protocols into modern standards, such as REST API.

In practice, this means the legacy SQL register is wrapped in a REST API layer, allowing modern applications to perform read and write operations without making changes to the original database schema. This protects the legacy system from unpredictable loads and table locking when connecting new interfaces.

Modern integration architectures must aim for near-zero downtime during the transition period by using asynchronous synchronization patterns. When a user signs a document in the EDM portal, the API Wrapper receives the request, validates it, and reliably delivers the changes to the database without requiring technical system downtime.

Data unification via domain metadata in UnityBase: from chaos to a unified model

One of the biggest challenges in integration is data model incompatibility. Older systems may store information in specific formats that do not meet the exchange standards of modern EDM platforms.

To solve this problem, the concept of domain metadata is applied. The UnityBase platform (a joint development of the Intecracy Group alliance, where InBase is a key developer) uses a model-driven architecture. It relies on a unified metadata model to describe the database structure, API behavior, and user interface.

Instead of writing hundreds of lines of code for mapping, developers describe the domain model declaratively. Based on metadata, UnityBase generates a REST API and manages interaction with the physical database. This allows legacy registers to be linked with new portals. Any changes in metadata are automatically translated to the API level, which significantly simplifies integration maintenance when document management requirements change.

Record-level security: implementing RBAC and RLS in a hybrid infrastructure

Legacy systems often have basic security models that limit access only at the entire database level. Modern EDM requires granular segmentation: a user should only see documents that correspond to their role in the organization.

During integration, end-to-end access control is implemented. The integration bus maps the metadata of legacy documents into a unified domain model, reliably ensuring access control at the RBAC (Role-Based Access Control) and RLS (Row-Level Security) levels. Rights verification occurs not only at the authentication stage in the web portal but also directly during the formation of the request to the legacy system.

For high-load projects or environments with increased requirements, official UnityBase documentation recommends commercial editions (Enterprise or Defence). They contain advanced mechanisms such as access control lists (ACL), attribute-level security, and detailed audit trails. For example, the Defence Edition supports integration with accredited key certification centers, DSTU encryption standards, and verification of server module integrity. This ensures that the entire document exchange cycle meets strict cybersecurity requirements.

Practical case: orchestrating departmental systems with Megapolis.DocNet

In large government institutions and corporations, accounting solutions, personnel registers, and disparate record-keeping systems usually operate simultaneously.

To combine this array into a single document management ecosystem, the Megapolis.DocNet system (a product built on the UnityBase platform) is used. It acts as an orchestration layer that links departmental databases. Megapolis.DocNet does not attempt to replace existing systems but integrates with them, ensuring an end-to-end electronic document lifecycle.

For example, building specialized integration subsystems for ERP Business Central with electronic document management services requires process orchestration. The orchestration layer receives primary documents from the accounting system, sends them to the counterparty via an external service, and returns the signing status back to the ERP. Integrating such services with accounting systems provides benefits for business operations through automated data exchange and holistic control.

ApproachData integrity risksImplementation speedMaintenance cost
Full replacement (Rip and Replace)High (risk of losing historical relationships)Low (years of development)Very high
Direct connection to legacy DBExtreme (violation of transactional integrity)Medium (requires custom scripts)High (due to fragile connections)
Integration layer on UnityBaseMinimal (controlled by metadata)High (low-code tools)Low (unified API)

Creating an integration bus preserves investments in legacy infrastructure, significantly minimizes the risks of information loss, and ensures compliance with modern EDM architectural and security standards.

FAQ

How can I connect a modern EDM portal to an SQL database without modifying it?

The API Wrapper pattern is used for this. An abstract software layer is created that transforms outdated interaction protocols into modern REST APIs. This allows new applications to perform read and write operations without making changes to the original database schema.

What risks arise when synchronizing data between legacy systems and cloud document management services?

Attempts to connect new portals directly to old tables often lead to violations of transactional integrity, unpredictable loads on the register, table locking, and prolonged downtime. Using an integration layer with asynchronous synchronization allows these risks to be avoided.

How can I ensure row-level security (RLS) for documents if the old system does not support modern security policies?

Access rights verification is moved to the integration bus level, which maps the metadata of old documents into a unified domain model. This allows for end-to-end access control using RBAC (Role-Based Access Control) and RLS (Row-Level Security) mechanisms directly during the request formation to the register.

Data sources

← All materials