"Just-in-Time Migration": A New Approach with the Faktor Zehn Business Partner (Faktor-IBP)
The replacement or renewal of a central business partner application involves numerous pitfalls. The reason for this is the tight integration with the entire application landscape. No matter how you cut it, all surrounding systems and especially batches are quickly affected and would have to be converted for the data records managed in the new partner: From an integration point of view, a "big bang" with first go live is hardly avoidable.
Faktor Zehn took this challenge into account from the very beginning when designing Faktor-IBP and developed an innovative solution: what if it were no longer necessary to migrate the old partner database (in tranches), but rather only and each time a data record is actually requested for detailed information or a change? "Just-in-time", in other words.
The focus here is on the function that Faktor-IBP can be operated in concert with other partner systems, assuming the role of the leading system ("primary"):
- When Faktor-IBP goes into production, the legacy partner systems remain online and respond to requests for partner data as usual.
- Partner data records have not yet been migrated. This means that the Faktor-IBP database is initially still empty.
- However, the interfaces for entering and maintaining new data in the legacy partner systems will be switched off and only the GUI of Faktor-IBP will be used, e.g. to enter new partners.
- The partner search in Faktor-IBP searches the legacy system and its own database. The results are combined into a hit list and displayed on the Faktor-IBP GUI.
- If the user selects an entry from the legacy system for detailed information or for editing, this partner is immediately transferred from the legacy system to Faktor-IBP. The fast REST services of Faktor-IBP allow for fast response times.
- During this "on-demand" transfer into Faktor-IBP, the foreign keys are also transferred and the user works on the partner via the Faktor-IBP GUI.
- The Faktor-IBP will transfer every write transaction to the legacy system, so that the conversion systems that have not yet been converted, and which still obtain the partner data from the legacy partner system, will be supplied with the current data.
- Strictly speaking, the partner object is only replicated "just-in-time" and the object in the legacy system is kept up-to-date. It is therefore possible to take the time to successively convert the conversion systems and thus complete the migration.
Changes to partner data that are caused by peripheral systems are routed to Faktor-IBP. Here, too, the following applies: If Faktor-IBP receives a change request for a partner number for which no data record is yet known in Faktor-IBP, Faktor-IBP imports this data record "on-demand", executes the request and reports the changes to the legacy system.
This therefore avoids a "big bang".
- Step 1: Replace the GUIs of the legacy systems with the Faktor-IBP GUI. The Faktor-IBP search takes the legacy systems into account and transfers partners "on-demand".
- Step 2: When all consumers of one of the legacy partner systems have been converted to Faktor-IBP, this legacy partner system can be switched off.
Benefits with Faktor-IBP's new approach
This "just-in-time migration" avoids many problems and pitfalls:
- The clerks do not have to work on the GUIs of different partner systems (depending on whether the partner has already been migrated to Faktor-IBP or not), but work exclusively with the GUI of Faktor-IBP.
- On the weekend of the Faktor-IBP go-live, not millions of partners have to be migrated.
- At this point in time, not all surrounding systems, batches and reports have to be migrated to the IBP dataset: they can continue to read the partner data from the legacy systems, which are always kept up-to-date.
- In addition, there is the opportunity to examine data records that have not been retrieved and transferred to Faktor IBP even after months to see whether they can or even must be deleted (due to data minimization according to Article 5 DSGVO or Code of Conduct).
This significantly reduces the complexity of introducing Faktor-IBP as a new partner system. Feel free to contact us if you are interested in discussing the requirements for the new approach.
You can find more information about Faktor-IBP on our homepage.
Your Faktor Zehn team
Author: Peter Stracke