How to migrate from point-to-point integrations to an iPaaS platform without stopping the operation

When a company integrated its systems however it could, a direct connection between the ecommerce and the ERP, another between the CRM and invoicing, another one between the POS and inventory, each of those connections works until they all stop working at the same time. The problem is not migrating to an integration platform: it is doing it without stopping an operation that depends on those connections every day.

This guide explains how to migrate from a point-to-point setup to a centralised iPaaS architecture with parallel coexistence, cross validation and a rollback plan, so the transition does not put orders, stock or invoicing at risk.

Quick summary

• A safe migration does not replace: it coexists. Both setups run in parallel until the new architecture proves it produces the same result.
• Implicit, undocumented business rules are the main risk of loss during migration.
• The correct order is from lowest to highest criticality: the approach is validated with whatever hurts least if it fails.
• No integration is switched off without a tested rollback plan, not just a written one.

Why you cannot simply switch off and switch on

A point-to-point integration is not just a cable between two systems. Over time it acquires implicit business rules nobody fully documented: an exception for a specific customer, a particular rounding, a field filled with a default value, a time window when it must not run. Replacing it overnight carries the risk of losing one of those rules and only discovering it when an order fails or an invoice comes out wrong.

There is also a comparison problem. Without a stage where both setups process the same data, there is no way of knowing whether the difference between the old and the new result is a migration error or a correction of a problem that already existed.

Stages of a migration without downtime

1. Inventory of existing integrations

Before migrating anything you have to know what exists: which systems are connected, what data they exchange, how often, and what transformation rules they apply along the way. This work is the same one described when building an integration map, and without it the migration is planned on assumptions.

One detail usually discovered here: there is almost always at least one active integration nobody remembered.

2. Prioritisation by risk and impact

Not all integrations are equally critical. It is advisable to migrate the lowest-risk ones first to validate the approach, and leave the most critical ones, such as invoicing or payments, for last. A simple matrix organises the discussion:

Criticality	Volume	Suggested order
Low	Low	First: validates the approach
Low	High	Second: validates performance
High	Low	Third: validates complex rules
High	High	Last: with everything already tested

The volume of each flow also helps size the cost of the target platform: in Weavee’s plans pricing is defined by the entities processed per month.

3. Parallel coexistence

The new integration is switched on alongside the existing one, without switching the latter off. Both receive the same data during a trial period. The new one can run in observation mode, processing and logging but not writing to the destination system, or in write mode against a test environment.

4. Cross validation

The result of both integrations is compared on the same real data. What has to be compared is not just the final result, but the edge cases: discounted orders, customers with incomplete data, products with variants, transactions at cut-off times. That is where the differences appear.

The approval criterion is best defined before starting: what percentage of matching, over what volume and for how many days.

5. Cutover and deactivation

Once validated, the original point-to-point integration is switched off. Only at this point does the platform, such as Weavee’s Universal Connection, become the sole owner of the flow. It is advisable to keep the previous integration deactivated but available for a period, not deleted, in case you need to go back.

What a rollback plan that actually works looks like

A rollback plan that is written and never tested is a statement of intent. To be useful it needs four elements:

• A clear trigger. Which specific condition activates the rollback: an error rate above a threshold, stalled orders above a count, a stock discrepancy beyond a margin.
• An owner with the authority to decide, available during the cutover window.
• A tested procedure. Switching the previous integration back on has to have been rehearsed, not just documented.
• A reconciliation plan. What to do with the transactions processed by the new integration during the failed period.

That last point is the most forgotten one and the one that generates the most work if it is not planned for.

The most common risks during migration

• Migrating everything at once, without phases, increasing the error surface.
• Not documenting implicit business rules and losing them in the migration.
• Switching off the previous integration before fully validating the new one.
• Not defining an objective approval criterion, and deciding the cutover by feel.
• Migrating during a period of high commercial demand.
• Underestimating the prior data normalisation work, which is usually the longest stage.

Frequently asked questions

How long should the parallel coexistence last? Long enough for the integration to process at least one full business cycle, including closes, demand peaks and exceptional cases. For order flows, a few weeks is usually reasonable; for monthly processes such as reconciliations, at least one full close.

Can you migrate with no interruption at all? In most flows, yes. In some specific cases, schema changes in the destination system, historical data migrations, a short, planned window may be necessary. The difference between a planned thirty-minute interruption and an unplanned outage is absolute.

What do you do with integrations nobody knows whether they are used? They are not simply deleted: they are monitored for a period to verify whether they have real traffic. If they do, they are documented and brought into scope. If they do not, they are deactivated reversibly and you watch to see if anyone reports it.

Is it advisable to migrate and redesign at the same time? No. Migrating by replicating the current behaviour and redesigning afterwards is slower on paper and far safer in practice, because it lets you distinguish between a migration problem and a design change.

What happens with historical data? Migrating flows does not force you to migrate history. It is advisable to decide explicitly what history needs to be available in the new architecture and what can remain queryable in the previous system, instead of migrating everything by default.

Checklist to migrate to iPaaS without stopping the operation

• Is there a complete inventory of the current integrations and their business rules?
• Are they migrated in phases, prioritised by risk and impact?
• Does the new integration coexist in parallel with the previous one before replacing it?
• Is the objective approval criterion defined before validation starts?
• Were the edge cases validated, not just the happy path?
• Is there a tested rollback plan, with a defined trigger and owner?
• Does the cutover window avoid periods of high commercial demand?

You may also be interested in reading:

• “iPaaS: what it is, how it works and how to choose a platform” • “Enterprise integration map: how to document systems, flows and owners before modernising your stack” • “SAP ERP automation: which processes to automate before scaling retail and ecommerce” Weavee accompanies the migration from point-to-point integrations to a centralised architecture, running both setups in parallel and comparing results on real data until it is confirmed that no business rule is lost.