Enterprise data after relocation

The relocation of Ukrainian enterprises to relatively safe regions has become one of the most important processes for the economy’s adaptation to full-scale war. However, physically transporting production equipment, opening a new warehouse, or resuming office operations is only part of the task. Full recovery of operations requires rebuilding corporate information systems, restoring integrations, synchronizing directories, and ensuring the accuracy of management data.

1. Business Relocation Alters Enterprise Information Architecture

Following the full-scale Russian invasion on February 24, 2022, Ukrainian enterprises faced the necessity of rapidly changing their geographical operational areas.

Production facilities, warehouses, offices, and employees were moved from combat zones to relatively safe regions. For some enterprises, this meant a temporary suspension of operations; for others, it involved changes in production cooperation, logistics routes, and organizational structure.

The state initiated a business relocation program that includes assistance with finding premises, transporting equipment, and resuming operations.

According to the Ministry of Economy of Ukraine’s report dated August 3, 2022, 692 enterprises have already relocated within the program, with 484 resuming operations in their new locations. The largest number of enterprises moved to Lviv, Zakarpattia, and Chernivtsi regions.

These figures demonstrate the scale of organizational changes but do not reflect the full complexity of the operational recovery process.

The company can physically relocate equipment, find personnel, and resume production, but at the same time, it may face disruptions in information links between its divisions.

For example, after relocating production to another region, the ERP continues to use old warehouse and production site codes. The CRM retains previous delivery addresses. The procurement system works with outdated suppliers. The corporate data warehouse generates reports based on an organizational structure that no longer corresponds to the company’s actual operations.

As a result, the information system formally functions but ceases to accurately describe the business. This is a fundamentally different problem than emergency server recovery.

If in the spring of 2022, the main priority was to preserve data and ensure the availability of critical systems, then by the end of summer, restoring the logical integrity of the corporate information architecture becomes increasingly important.

It is necessary not just to bring ERP, CRM, or Data Warehouse back online, but to adapt them to new business processes.

2. Physical Relocation and Information Relocation Are Different Processes

In a classic infrastructure project, migrating an information system involves moving hardware, databases, application software, and network configurations.

During the relocation of the company itself, significantly more changes occur.

New production addresses, warehouses, supply routes, employees, contractors, and operational rules emerge.

Some of the previous business processes may become irrelevant. Others require temporary simplification or transfer between departments.

• Thus, information relocation covers at least four levels:
• Infrastructure. Ensuring the availability of servers, networks, storage systems, and workstations.
• Application. Reconfiguring ERP, CRM, WMS, electronic document management, and other systems.
• Integration. Restoring information exchange between systems and external counterparties.
• Semantic. Reviewing directories, organizational structures, business rules, and metric definitions.

The last level is often underestimated.

Suppose a company is relocating its main warehouse from the Kharkiv region to the Lviv region. For an IT administrator, the task might seem simple: change IP addresses, create new users, and ensure access to the ERP.

However, for the data management system, additional questions arise.

Is the new warehouse a legal and operational continuation of the old one? Should it inherit warehouse balances? How to account for goods in transit? How to change territorial analytics? What to do with orders placed before the relocation but fulfilled after it?

The system administrator cannot independently determine the answers to these questions. They require the involvement of finance, logistics, and operations departments.

3. Information Flow Inventory

The first step after restoring basic systems should be to determine the actual state of integrations.

The ERP exchanged data with CRM, WMS, accounting systems, electronic document management, production equipment, and corporate data warehouse.

Part of the exchange was done via API, part via direct database connections, file directories, messages, or batch ETL processes. After relocation, certain integrations may remain functional, even though their business assumptions are no longer valid.

For example, an ETL process successfully retrieves data from an old warehouse, but this warehouse no longer performs operations. Consequently, the analytical system receives technically correct, but incomplete data.

Integration Audit Matrix

For each flow, it is necessary to define the owner, source, receiver, transfer method, update frequency, criticality, and recovery rules.

Dependencies between flows should be defined separately. For example, updating warehouse balances may depend on the prior loading of the warehouse directory.

Executing integrations in the wrong sequence can lead to the appearance of incorrect records even in the absence of technical errors.

4. New Data Exchange Architecture Between Sites

For a distributed enterprise, it is advisable to gradually abandon integrations that are rigidly tied to the physical location of the server.

Direct connection of each branch to the central database can create performance, security, and availability problems.

A more robust solution is a controlled integration layer that separates operating systems and ensures data exchange through defined interfaces.

Example Architecture After Relocation

• Production
• Warehouses
• Offices and Sales
• Secured APIs · Queues · Batch Exchange
• Integration Layer
• ETL / CDC · Message Control · Routing · Logs
• ERP / CRM
• MDM
• DWH / BI
• Flow Monitoring · Data Quality · Checkpoints · Reprocessing

The integration layer does not necessarily have to be a single physical server.

On the contrary, its components can be located on different sites if the architecture supports queues, buffering, retransmission, and state control.

The separation of functions is fundamentally important.

The operating system is responsible for accounting for business transactions. The integration layer is responsible for controlled information transfer. MDM is responsible for the consistency of critical directories. DWH is responsible for consolidating historical and analytical data.

This distribution reduces the number of hidden dependencies.

5. ETL and Change Data Capture in Unstable Connection Environments

In a distributed environment, the choice between batch integration and real-time change transfer should be determined by business requirements.

Not all information requires instant synchronization.

For example, updating management reports once a day may be acceptable. However, changes in stock balances between ERP and WMS may require a significantly shorter delay.

Several approaches are used for this.

As of August 2022, for such tasks, one can use, in particular, Apache Kafka 3.2, Apache Spark 3.3, Apache Airflow 2.3, and Debezium branch 1.9.

These tools solve different tasks. Kafka provides a stream processing infrastructure, Debezium allows capturing changes from supported databases, Spark processes large volumes of information, and Airflow coordinates batch processes and task dependencies. The availability of the mentioned branches corresponds to August 2022. It is important not to confuse the presence of a technology with the necessity of its application.

A company that has four integration flows and exchanges several thousand records per day does not always need a separate Kafka cluster. A simple, documented, and controlled batch process will sometimes be more reliable.

The Problem of Resubmission

Suppose a branch sends a shipment notification to the central ERP.

After the message is sent, the connection is lost, and the branch does not receive confirmation.

The system does not know if the ERP has processed the document.

If resubmission creates a new shipment, duplication occurs.

To prevent this, idempotent processing is required: the repeated arrival of the same logical operation should return a previously recorded result, rather than creating a new document.

A unique message identifier can be used in a relational database.

CREATE TABLE integration_inbox (
    message_id UUID PRIMARY KEY,
    source_system VARCHAR(50) NOT NULL,
    received_at TIMESTAMPTZ NOT NULL
        DEFAULT CURRENT_TIMESTAMP,
    payload JSONB NOT NULL,
    status VARCHAR(20) NOT NULL
        DEFAULT 'NEW'
);

Example of receiving a message in PostgreSQL:

INSERT INTO integration_inbox (
    message_id,
    source_system,
    payload
)
VALUES (
    '6ea0ec17-f65a-474d-901d-ae973d910d67',
    'WAREHOUSE_LVIV',
    '{"document":"SH-1048","quantity":25}'::jsonb
)
ON CONFLICT (message_id) DO NOTHING;

The ON CONFLICT clause prevents the creation of a duplicate record with the same identifier.

However, this is insufficient to guarantee the idempotency of the entire business operation. Creating an ERP document and recording the message status must be performed consistently, using a transaction or a specially designed processing mechanism.

For critical integrations, it is also advisable to store the execution result and a retry log.

6. MDM: Geography changes should not break reference data

One of the most complex challenges after relocation is master data management.

This primarily concerns the master data:

• enterprises and divisions;
• warehouses and production sites;
• counterparties;
• product nomenclature;
• employees;
• territories and logistics routes;
• cost centers;
• organizational structure.

Under normal circumstances, such master data changes gradually. During mass relocation, changes may occur simultaneously in several systems.

For example, an enterprise moves its main warehouse but leaves a small portion of inventory at the previous location. If the old warehouse is simply renamed to the new one, the system will lose the ability to distinguish historical operations from actual goods movement.

Therefore, it is important to separate the physical location, the logical accounting unit, and its identifier.

Warehouse Master Data Change Scenarios

Slowly Changing Dimensions approaches, specifically SCD Type 2, can be applied here.

They allow preserving the history of master data attribute changes without overwriting their past states.

SQL Example of a Historical Master Data Table

CREATE TABLE dim_warehouse (
    warehouse_sk BIGSERIAL PRIMARY KEY,
    warehouse_code VARCHAR(30) NOT NULL,
    warehouse_name VARCHAR(200) NOT NULL,
    region_name VARCHAR(100),
    valid_from DATE NOT NULL,
    valid_to DATE,
    is_current BOOLEAN NOT NULL
);

Conditional history of a single warehouse:

This model is acceptable if the company has formally defined the relocation as a continuation of the same logical unit.

If, however, the new warehouse is a separate accounting entity, it must be assigned a different business code. Crucially, the SCD Type 2 model is a method for preserving history in an analytical dimension. It does not replace the procedures for moving actual inventory balances in the transactional ERP.

7. Data Warehouse: How to Maintain Reporting Comparability

Relocation changes not only operational data but also the logic of corporate analytics.

Suppose a company has been generating reports based on five regional divisions for several years.

In 2022, two divisions temporarily ceased operations, a third relocated, and a fourth began performing additional functions.

If the DWH automatically uses the current organizational structure for the entire history, analytical reports may lose comparability. For example, sales volumes for 2021 will be attributed to new regions where the company did not actually operate at that time.

To avoid this, two possible analytics modes are needed. The historical mode shows the company’s operations according to the organizational structure that was in place at the time of the transactions.

The current management mode allows for regrouping historical indicators according to the new structure for planning and comparison.

Both modes can be useful, but they cannot be mixed without a clear definition of the methodology.

Analytical Data Warehouse Architecture After Relocation

For such tasks, it is advisable to store not only the current attribute values but also the dates they became effective.

Comparison of indicators before and after changes in the business model requires special attention. For example, the cost of logistics for August 2022 may be significantly higher due to changes in routes, transportation costs, and supply conditions. A simple comparison with August 2021 without considering these changes can lead to erroneous management conclusions.

Therefore, corporate analytics must preserve the context in which the indicators were formed.

8. Data Quality after Relocation

The physical relocation of an enterprise creates additional sources of information errors.

Some operations may temporarily be performed manually. Individual systems may operate autonomously. Certain documents may be processed with delays.

As a result, information obtained from different sources may have varying time characteristics and levels of reliability.

Unnoticed discrepancies are particularly dangerous. For example, the ERP may show the availability of goods that are physically located in an inaccessible warehouse.

From a formal perspective, the stock exists. However, it cannot be used for shipment planning.

Therefore, traditional indicators of data completeness and correctness may be insufficient.

It is necessary to additionally determine the operational suitability of information.

Quality Control Metrics

For warehouse systems, it is advisable to separate the physical quantity of goods, its accounting quantity, and the quantity available for sale.

Conditional example:

If the analytics system only considers the total balance, it may overestimate the company’s actual order fulfillment capacity.

This demonstrates that Data Quality is not just a matter of technical record correctness. It directly impacts management decisions.

9. Restoring Information Resources from Partially Unavailable Systems

A separate problem is a situation where a company has lost access to part of its information sources.

For example, the central ERP is saved, but the local database of production equipment remains at an inaccessible site. Or the accounting system is working, but some primary documents were not synchronized in a timely manner.

In such cases, data cannot be automatically considered lost forever.

Information may be partially stored in:

• backups;
• electronic document management;
• exchange files;
• partner systems;
• archival analytical databases;
• integration logs;
• email;
• local copies accessible to authorized employees.

However, restoring information from alternative sources requires a clear procedure.

It is necessary to establish the origin of records, their creation time, completeness, admissibility of use, and possible conflicts with other sources.

Practical Approach to Reconstruction

First, a list of missing information objects is formed. Next, potential recovery sources are identified for each object.

After that, a temporary data area is created where the information undergoes verification.

Only after confirmation by the business owner can the data be transferred to the main system.

This approach is particularly important for financial documents, warehouse operations, and counterparty directories. Automatic loading of unverified records can create more problems than their temporary absence.

10. Practical Scenario: Relocation of a Manufacturing Enterprise

Let’s consider a hypothetical machine-building enterprise that, before the full-scale war, had production facilities in the eastern part of Ukraine, a central warehouse, and several regional representative offices.

The enterprise uses:

• ERP for production and financial accounting;
• WMS for warehouse management;
• CRM for customer relations;
• electronic document management;
• MDM for corporate directories;
• DWH for management analytics.

Due to the threats of combat operations, some equipment and personnel have been moved to the western region. Server infrastructure has been restored at a backup site.

However, after launching the systems, it was found that a significant portion of information processes require reconfiguration.

Phase 1. Defining the new operational structure

The enterprise will formalize the new structure of production, warehouses, departments, and responsibility centers.

Each change is accompanied by defining the effective date.

Phase 2. Master Data Harmonization

MDM is used to create new accounting units and update information about existing ones.

Old identifiers are not deleted, as they are necessary for maintaining historical relationships.

Phase 3. Restoring Integrations

ERP–WMS, CRM–ERP, and ERP–DWH integration processes are being reconfigured according to the new information routes.

For critical flows, message reprocessing control is introduced.

Stage 4. Balance Reconciliation

The enterprise conducts a physical inventory of available stock. The results are compared with the ERP, after which documented adjustments are made.

Goods remaining at inaccessible sites are accounted for separately with the appropriate status.

Stage 5. Analytics Rebuilding

The Data Warehouse receives a historical model of organizational changes.

Two sets of reports are generated for management: historical enterprise activity and current operational structure.

Stage 6. Restoration of the Regular Management Cycle

After verifying critical integrations, the enterprise returns to regular planning of procurement, production, logistics, and sales.

This is a hypothetical scenario demonstrating an architectural approach, not a description of a specific implemented project.

11. 60-Day Information Relocation Roadmap

Actual timelines depend on the enterprise’s scale and the availability of personnel and systems. Critical operations may be restored significantly earlier, while full historical data reconciliation will require additional time.

12. KPIs for Outcome Evaluation

These values are examples of target parameters. For a specific organization, they should be determined considering business risks. It is especially important to evaluate not only the availability of integrations but also the quality of their results.

A system that consistently transmits incorrect data cannot be considered successfully restored.

13. Risks and Common Errors

The first risk is the mechanical transfer of the old organizational model to new conditions.

If the physical location and functions of departments have changed, corporate directories must reflect these changes.

The second risk is uncontrolled creation of new codes.

When each branch independently creates directories of warehouses, materials, and counterparties, the enterprise quickly accumulates duplicates.

The third risk is loss of change history.

Overwriting old addresses and organizational attributes without preserving previous states can distort management reporting for past periods.

The fourth is the lack of integration logging.

Without preserving message identifiers and checkpoints, it is difficult to determine which operations were performed before the failure and which need to be repeated.

The fifth is insufficient verification of information quality after recovery.

Technically correct data loading does not guarantee its compliance with the actual business state.

The sixth is excessive technological complexity.

In conditions of limited resources, it is advisable to first ensure the reliability of critical processes, and only then modernize the architecture.

Seventh is the neglect of information security. New sites, remote employees, and temporary integrations increase the number of access points to corporate data.

14. Intecracy Group Competencies

Enterprise information relocation is a complex task that combines data management, application integration, and infrastructure development.

Within Intecracy Group, the relevant technological directions are represented by the competencies of several companies.

Data Management IG (dmig.com.ua) specializes in ETL, MDM, Data Quality, Data Warehouse, Data Lake, corporate analytics, and Data Governance. These competencies can be applied to restore information flows, harmonize directories, preserve historical data, and ensure reporting accuracy after changes in the enterprise’s organizational structure.

IQusion IT (iqusion.com) represents system integration, electronic document management, BPM, and business process automation. These areas complement data management at the application logic level: document routing, approvals, intersystem exchange, and restoration of end-to-end processes.

Softline IT (softline.kiev.ua) has an infrastructure specialization: server systems, networks, data storage, and corporate IT infrastructure. These competencies are important for ensuring the physical and network availability of information systems after the enterprise’s relocation.

SL Global Service (sgs4business.com) works in the area of cloud integration, virtualization, and hybrid infrastructure. These technologies allow for considering backup placement of application systems and distribution of computing resources between sites.

The combination of the specified specializations demonstrates that restoring corporate IT requires not only launching servers but also a comprehensive rebuilding of the information architecture in accordance with actual business processes.

the enterprise must preserve not only data but also its content

The relocation of Ukrainian enterprises has become an important business response to the challenges of full-scale war.

However, the physical movement of equipment and the resumption of operations at a new site do not guarantee the restoration of full-fledged management.

Corporate information systems must correspond to the actual organizational structure, logistical connections, asset location, and operational rules.

Data integration and master data management are of particular importance. Without them, even functional ERP, CRM, WMS, and DWH systems can generate contradictory information.

Accordingly, the first task is to inventory information flows and identify sources of truth.

The second is the controlled modification of reference data while preserving history.

The third is the restoration of integrations, considering unstable communication channels, the possibility of retransmission, and the need for transaction reconciliation.

The fourth is the restructuring of analytical models so that management reporting does not lose comparability.

The fifth is the formation of a quality control system that considers not only the technical correctness of the data but also the possibility of its actual use.

For Ukrainian enterprises, August 2022 is a period when the issue of preserving information systems is gradually supplemented by the issue of their compliance with the new economic reality.

Key takeaway: successful information relocation is not about moving servers and databases, but about restoring the enterprise’s integrated digital model.

This model, in particular, ensures business manageability, allows for the maintenance of production and logistics, analysis of performance results, and adaptation to further changes.

And the more complex the enterprise’s geography becomes, the more crucial Data Integration, MDM, Data Quality, and systematic management of corporate information resources become.