30/08/2026 10:29 am
Topic starter
Community
Connect with us and enhance your M-Files experience using Extension Kit for M-Files. Here is how to get started.
Notifications
Clear all
0
Use case:
Client has multiple business units each having their own set of accounts in the ERP system. These have been synchronized into M-Files via a View in the ERP systems SQL database where entities from each set of accounts get joined while adding a preposition code for each business unit. So 5 sets of Customers are joined into one table in the View, and this table is then synchronized into M-Files using the standard M-Files OLE DB connector. This makes Customer an external object type, where the ERP system is the master. Similar connections are made for Projects and Employees.
Now the client is in the process of switching to a new ERP system and will do so in a gradual process where one business unit at a time switches over to the new system. This creates a situation where the old ERP system can no longer be the master database for Customers, Projects and Employees. Yet we still need to pull data from the old ERP system into M-Files and mix it with data from the new ERP system to keep all business units up to date in the vault.
There are several possible solutions in this situation:
- Create a new separate SQL database and join data from both ERP systems into this database, and then use it as master and synchronize it with the M-Files vault.
Connecting to the old on premise system is simple. Connecting to the new cloud based system is not at all simple - it requires tools similar to the Ext. Kit HTTP Integration. - Create all existing Customer, Project and Employee objects from M-Files into the new ERP system for all business units, and then make the new system the Master.
When new objects are created we then need to make sure they are also created in the old ERP system for business units still recording their financial transactions in that system.
We cannot pull any updates on those objects created directly in the old ERP system into M-Files because the new ERP system is now the Master in the External object type. - Create all new Customer, Project and Employee objects from the new ERP system into the old ERP system's database and keep that old database as Master in the External object type until all business units have switched over to the new ERP system some 8 months down the road.
We have the means to do so via Robotic Process Automation if required.
We would not be able to pull any status changes made in the new ERP system back into M-Files or transfer them to the old ERP system. - Make Customers, Projects and Employees internal object types in M-Files and set up connections to both external ERP systems.
The client intents to initiate all new object creations directly in M-Files, and we have the means in place to transfer each object creation to the relevant external system. We can use Robotic Process Automation on the old system and HTTP Integration on the system. This way we can make sure both ERP systems have the relevant Customers, Projects and Employees for each business unit.
However, financial records may lead to changed statuses internally in the ERP systems. A project may get closed, an employee may leave the company and so on. We need to pull those changes back into M-Files somehow. We can pull data from the new ERP system using HTTP integration. On the old system we would have to use SQL Integration in this setup.
As far as I can tell it is only possible to send a SQL request on one object/entity at a time and use the response to update that object in M-Files.
I am looking for an option to run a scheduled nightly update on all Customers, Projects and Employees. Is that possible?
2 Answers
0
03/09/2026 11:15 am
Hi,
At the moment, create and the bulk update approach we have available in the HTTP Integration module is not yet supported in the SQL Integration module. This functionality is already on our roadmap, but it has not been implemented yet.
If using SQL Integration for the nightly bulk update is the only feasible option in your setup, I can check with our development team whether we could prioritize this task and potentially make it available sooner.
However, based on the setup you described, our recommendation would be to make the new ERP system the source of truth and primarily focus on synchronizing the data from the old ERP system into the new one during the transition period. M-Files could then receive all Customer, Project and Employee data from the new ERP system using HTTP Integration.
This would be the cleanest approach from the M-Files perspective, as it would give you a single source of truth throughout the transition and would not require additional changes to the M-Files integration once all business units have moved to the new ERP system in approximately eight months.
Best regards,
Nika
Topic starter
03/09/2026 12:01 pm
Thank you @nikatilic,
The challenge is in the interim period which will last at least 8 months. Obviously, after that period the new ERP shall be Master.
During the interim period changes will be made in both ERP systems to the business units running in those systems. Currently the only means to get data out the old system is through a direct OLE DB connection to M-Files, where the old ERP system is Master and the synchronized object types are registered as external object types. I was hoping to brake that lock in and use SQL Integration to pull changes into M-Files during this period.
I could perhaps solve this by creating a new vault only with the external object types from the old system and then use the Vault to Vault module to transfer any changes into the production vault. Have not tried to use Vault to Vault module yet, but it looks like it might be able to handle this challenge?
0
03/09/2026 1:15 pm
Hi @karl-lausten,
Yes, Vault to Vault could be a possible workaround, but I think there may be a simpler option for the transition period.
You could keep the object types connected to the old ERP as temporary object types, for example Project Temp, Customer Temp and Employee Temp, and create/use the actual Project, Customer and Employee object types for the new ERP. This way, the existing synchronization with the old ERP can continue running for the business units that have not migrated yet, while the new ERP can already become the source for the final object types.
Once all business units have migrated, the temporary object types can be retired and the existing references can be aligned with the new object types based on a common identifier.
Alternatively, the separate vault + Vault to Vault approach you suggested could also work. Just keep in mind that Vault to Vault is not supported in the newer M-Files Cloud versions. If the environment is on-premises, it could still be a valid workaround for the transition period.
Topic starter
03/09/2026 1:55 pm
Hi @nikatilic,
Well it is not quite that simple. The objects are used in automated workflows, customers are related to cases, documents related to cases and customers and so on. It would be rather difficult to manage that with a mix of temporary and ordinary object types. And users would have a really hard time finding their way in that mix.
Anyway, the vault is on premise, so that is not an obstacle. Will test Vault to Vault to see if I can make that work.
Thank you for your ideas and input.
