# Should I migrate from Apromore Apromore is process intelligence, not a migration tool. Do not move records because a path was discovered. **Published:** 2026-07-02 **Canonical:** https://synconai.com/should-i-migrate-from-apromore **Author:** SynconAI Architecture Team ## In short Salesforce completed the Apromore acquisition on 3 November 2025. Apromore is process intelligence, not a migration tool. Case history already records status changes on a case you have. A discovered path is a picture of that history. Do not move records because a path was discovered. Record migration is a different quote. This page states no price and no end date. ## Sources - **Salesforce Signs Definitive Agreement to Acquire Apromore** (retrieved 2025-11-03) https://www.salesforce.com/news/stories/salesforce-signs-definitive-agreement-to-acquire-apromore/ > Salesforce completed its acquisition of Apromore on November 3, 2025. ## What to take away - Apromore is process intelligence, not a migration tool. The close was 3 November 2025. - Case history already records how a case changed. Discovery reads that log. It does not load records. - Do not move records because a path was discovered. - Alternatives sit unranked. This page invents no AppExchange listing, price, or shutdown date. ## The guide A buyer pastes a field map for Account under a title that says migrate Apromore. The field map may be a real need in another project. It is the wrong object here. Apromore is process intelligence. It reads how work actually moves. It is not a data migration tool. A partner who opens with a data loader has brought the toolkit for a different trade, and a discovered path is not a reason to relocate the records the path described. The only sentence this page quotes from the announcement is the completion line. "Salesforce completed its acquisition of Apromore on November 3, 2025." Read it as a close, not as a promise that your cases will move house. ## Should you migrate Migrate your attention, if you migrate anything, towards a log and a decision. The process, in one sentence a frontline person would accept. The events you will include. The period the log covers. The decision the picture must inform, written before the picture exists. If you cannot write the decision, you are buying a drawing. Do not call that a migration of records. Do not migrate because the acquisition completed on 3 November 2025. The cited page does not publish a shutdown date, and it does not instruct you to load data. If cases do need to move house, hire that work under its own name, with a match rule and a rehearsal. Keep this page for how the work behaves. The two quotes must not share a fee. ## A discovered path is not a move order Discovery lays events in order until you recognise the picture, including the ugly wait a procedure document never mentioned. That picture can support a decision you already had the authority to make: a queue, a required field, a handoff. It cannot, by itself, authorise a new org, a deleted object, or a customer promise. The log shows a wait. A person decides whether the wait may change. Do not move records because a path was discovered. The path is evidence about records that already live somewhere. Moving them is a different act, with volumes you measure yourself and a way back. This page will not write that scope. Writing it here would pretend the acquisition did the loading. It does not. ## What the software is now Salesforce owns Apromore. The completion date is 3 November 2025. What the software is now is process intelligence. It is not a migration utility, and it is not a screen this page will draw. The cited page does not publish a price. Whether a process-intelligence product is on your contract is a question for that contract. Leave the cell blank if you do not know. A blank is cheaper than a line you cannot explain. What you will not decide from a model, even after you trust the picture: a headcount figure, a tool purchase justified only by a drawing, a promise to a customer. Those decisions have owners outside the log. ## The three pages This page answers whether you should migrate, what the software is now, how a log compares with native history, and which alternatives sit unranked. It does not price a data load. The implementation page is [Apromore process intelligence](/apromore-process-intelligence-salesforce). Use it for an event log and the decision the model must inform. The what-happened page is [What happened to Apromore](/what-happened-to-apromore). Use it for ownership, the date, the blank price, and the absent end date. The integration page is [Integrating Apromore with Salesforce](/integrating-apromore-with-salesforce). Use it when a log must be extracted from history you already store. Extraction is not insertion. If the brief says data loader, you are on the wrong page. ## Versus the history Salesforce already stores Case history already records that a case changed status, who changed it, and when, for the history your org retains. Field history, where you have turned it on for a field, already records the old value, the new value, and the user. A report can count those changes. A list view can show the cases still open. Those native features already answer what happened to a record you have. They do not copy the record into another org. They do not invent the steps that happened off to the side, in a spreadsheet the log cannot see. Only after that description does a comparison count. Apromore reads a log of events so you can see loops and waits across many items of work. It is not a second copy of the case, and it is not a migration tool. A path discovered from history is a reading of history. The cases stay where they are unless a separate migration, with its own rehearsal, says otherwise. Do not move records because a path was discovered. Off-system work is the usual surprise. The history will not show the spreadsheet. A person who does the work will. Budget time for that conversation before you treat the picture as complete enough to justify any change, let alone a move of data. A model that ignores the spreadsheet will describe a process you do not run. ## What you must not move Do not move Accounts, Cases, or any other records because a diagram showed a loop. Do not let a discovered path become a field map. Do not treat an export of history as permission to insert that history somewhere else under this name. If identifiers do not tie events to one item of work, you do not have a process. You have a pile of timestamps. The first service is the tie. Price it as analysis, not as a loader. Clocks differ between systems. History objects are incomplete. A quote that says the log is just an export has not looked at your history. Ask for the object and the fields. If they cannot be named, you are early, and you are not migrating. ## Alternatives, without a rank People search for alternatives after the acquisition, and for an alternative on AppExchange. This page has not been shown an AppExchange listing. It will not invent a listing, a rating, or a rank. One way is to keep reading case history and reports you already run, and make one operational change a supervisor can see. Another way is to build one event log for one process and decide one question from it, without moving records. Another way is to run a record migration under its own quote, with no claim that process intelligence performed the load. Another way is to evaluate a different analysis tool on your own criteria. None of these is placed first. The gate is whether the brief is a log and a decision, or a loader. A loader fails this page's gate. It may still be a legitimate other project. It is not this one. ## A walkthrough you can finish on paper Write the process sentence. Write the event types, and the ones you will ignore on purpose. Write the period. Write the decision. Write the people who must recognise the picture, including someone who works the queue. Write the system that holds the timestamps. Write, in a sentence you will not cross out, that no records will be moved because of what the picture shows. Stop if the decision line is empty. Take the log plan to the implementation page. Leave price and shutdown on the what-happened page. Take the extraction, not an insert, to the integration page. If a field map appears, move it to the other quote. ## After you can see the path Act on one finding you can actually change: a queue, a skill, a required field, a handoff. Do not act by relocating the records that revealed the finding. Add a second process only when someone who does the work agrees the first picture includes the off-system step. A pack goes wrong when the title says migration, the attachment is a field map, and a quarter is typed for cutover. Strip it back. One log. One decision. No data movement. No price. No end date. No screen. ## What the log still cannot see History in Salesforce is only as complete as the tracking you turned on and the retention you keep. A status your team uses as a parking space will look like work. Decide, before anyone draws a path, which events you will ignore on purpose. Clocks in an outside system will not match the org. Identifiers get reused. A migration of records would have to solve those problems with a match rule and a rehearsal. Process intelligence does not get to skip them by calling the file an insight. If the tie between events and one item of work is missing, stop. You have timestamps. You do not have a process, and you certainly do not have a load. The people who must trust the picture are part of the decision to proceed. A process owner. Someone who works the queue. Someone who can say a step does not happen, or happens in a sheet the log will never show. Budget that conversation. A picture that ignores the sheet will send you to change a queue you do not actually use, or worse, to move cases that were never the bottleneck. One finding you can change is enough for a first cycle. A second process waits until the first picture has survived that conversation. Licences sit in their own cell. The acquisition does not tell this page that a product was added to your contract. Ask. If the answer is that you do not know, write that you do not know. Do not convert the unknown into a data-migration project so the unknown has a task list. The task list would move records. That is the act this page forbids. Bring one case the queue already argues about, with the history still on it, and sit with the person who worked it. Ask which status was real work and which was a parking space. Ask what they wrote in the sheet the history cannot see. That conversation is the migration of understanding, if you want a word for it. It is not a migration of the case. The case stays. If the conversation cannot be scheduled, you do not yet have a reader for the picture, and a picture without a reader will be asked to justify a load. Refuse that ask in the meeting, while the attachment is still a field map and not a project plan. ::: note Apromore is process intelligence, not a migration tool. Do not move records because a path was discovered. The close was 3 November 2025. Case history already records the changes. This page gives no price, no screen, and no end date. ::: | Decision | You may proceed when | Stop when | | --- | --- | --- | | Use the log | A process, a period, and a decision are named | The brief is a field map | | Records | They stay where they are | A path is treated as a move order | | Native comparison | You have said what case history already stores | The comparison promises a data load | | Other migration | It has its own quote, match rule, and rehearsal | It is priced as process intelligence | | Alternative | The ways sit unranked | An AppExchange listing or a rank was invented | | Price and end date | Both cells are blank | A figure or a quarter was typed to fill a template | Bring the table to the meeting. If records are in the first row, you have changed projects. The implementation page can price a log and a decision. It cannot price a loader wearing this name. ## Questions ### Should I migrate from Apromore to Salesforce? Do not migrate records under this name. Apromore is process intelligence. Salesforce completed the acquisition on 3 November 2025. Use it, if you use it, for an event log and a decision. A data load is a different quote. This page states no price and no shutdown date. ### What is Apromore software now? Apromore is process intelligence. It discovers how work actually runs. Salesforce owns it after 3 November 2025. It is not a migration tool, and this page does not describe a current screen or an end date. The cited page does not publish a price. ### How does Apromore compare with native Salesforce history? Case history already records status changes, who made them, and when. Field history records old and new values where you track a field. Reports can count those changes. Apromore reads a log across many items of work. It does not replace that history, and it does not move the records. ### What are the alternatives after the Apromore acquisition? This page does not rank alternatives and has not been shown an AppExchange listing. Ways that sit side by side include using the history and reports you have, building one log for one decision, running a separate record migration, or evaluating another analysis tool yourself. ### Should we move records because a process path was found? No. Do not move records because a path was discovered. The path describes work already stored. Moving records needs its own scope, volumes, match rule, and rehearsal. Process intelligence does not do that load. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Salesforce consultancy (https://synconai.com/salesforce-consultancy).