Apromore: the quote is a log, not a migration

A buyer pastes "apromore data migration to salesforce quote" into a brief and attaches a field map for Account. The field map is a real need in some other project. It is the wrong object here. Apromore is process intelligence. It discovers how work actually runs, simulates a change, and helps you optimise the path you have evidence for. It does not load records from one org into another. A partner who opens with a data loader has brought the toolkit for a different trade.

The line you can date is this one. "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. If your cases do need to move house, hire that work under its own name, with its own rehearsal, and keep this page for the question of how the work behaves.

#An event is not a record you relocate

A case has a created time, a set of status changes, an owner change, and a close. Those are events. Laid in order, for many cases, they are a log. The log shows loops, waits, and steps that a procedure document never mentioned. Discovery is reading that log until the picture is one you recognise, including the ugly part. Simulation asks what would happen if a wait were shorter or a step were removed, using the log as the evidence. Optimisation is the decision to change something you can actually change: a queue, a skill, a required field, a handoff. It is not a slogan pasted on the model.

None of those steps inserts an Account into a new org. If someone needs that insert, they need a migration scope: objects, volumes you measure yourself, a match rule, a rehearsal, a way back. This page will not write that scope, because writing it here would pretend the acquisition did the loading. It does not.

Bring a log you can export, or a plan to create one from history you already store. Case history, opportunity stage history, a field audit, an external system that already timestamps the handoff. Name the system. Name the identifier that ties events to one item of work. If you cannot tie them, you do not have a process. You have a pile of timestamps. The first service is the tie, and it should be priced as analysis, not as a loader.

#What the quote has to name

The process, in one sentence a frontline person would accept. "How a case moves from open to solved for this record type." Not "enterprise operations." The event types you will include, and the ones you will ignore on purpose, such as a status your team uses as a parking space. The period the log covers, chosen by you, long enough to include the stall you care about. The decision the work must inform, written before the model exists. If you cannot write the decision, you are buying a picture.

Who must trust the as-is map. A process owner. Someone who works the queue. Someone who can say that a step in the picture does not happen, or happens off-system. Off-system work is the usual surprise. The log will not show the spreadsheet. The person will. Budget time for that conversation. A model that ignores the spreadsheet will optimise a process you do not run.

What you will not decide from the model. Headcount as a number this page refuses to print. A tool purchase justified only by a picture. A customer promise. The model can show a wait. It cannot, by itself, authorise a redundancy or a new product. Those decisions have owners outside the log. Say so, or the picture will be asked to carry them.

Licences you already hold, and whether process intelligence is among them. This page will not assume the acquisition put a product on your contract. Ask. Leave the cell blank if you do not know. A blank is cheaper than a line item you cannot explain to procurement.

#What cost means before anyone prices it

Cost is extraction, modelling of one process, the workshops with the people who recognise the work, and the hours to act on one finding. Extraction is harder than a slide suggests. History objects are incomplete. Clocks differ between systems. Identifiers get reused. A quote that says the log is "just an export" has not looked at your history. Ask them to name the object and the fields. If they cannot, they are early.

Internal hours dominate. The process owner has to sit with the picture and mark what is real. The queue has to confirm the loop. An admin has to explain a status nobody remembers adding. Those hours are the cost of a map you can trust. Skip them and you will optimise a fiction, then pay again to undo the change.

Out of scope: record migration, a golden anything, a new case model, an agent that closes the work, a simulation presented as a forecast of revenue. Simulation here is about the path. It is not a financial forecast, and this page will not print one. If the decision is a forecast, you are on the wrong brief.

One finding, acted on, is the acceptance test. You chose the decision in advance. The log supports a change or it does not. You make the change in the queue, the field, or the handoff, at a size you can reverse. Then you read the next period of the log. If you cannot name the finding in a sentence, the pilot is a demonstration. Demonstrations are fine. They are not a result. Price them as demonstrations.

#The services people confuse with migration

A search for migration services will keep arriving. Answer it in the quote so procurement can see the refusal. You will extract events. You will not upsert Accounts. You will not deduplicate the database as the main act. You will not treat a field map as the deliverable. If a field is missing and the log needs it, adding the field is a small platform change in service of the log. It is still not a migration.

Cleanup of history can be in scope when the log is unreadable without it. That cleanup should be specified: which status is noise, which clock you will trust, which items you will exclude. It is a filter. A filter is not a reload. Write the filter down so the next month's log is comparable. Changing the filter after you have a picture makes the picture incomparable, and someone will call the change an improvement.

Simulation needs a lever you really have. Removing a step that the law requires is not a lever. Shortening a wait that depends on a customer is a weak lever. Changing a required field your own team controls is a lever. Ask the partner to name the lever before they run the scenario. A scenario with no lever is a tour.

Optimise means a change in the work, measured on the next log, against the same event definitions. It does not mean a percentage this page supplies. Your before and after are yours. If the period is short, say the result is early. Early is an honest status. A precise saving invented to fill a steering cell is not.

#The hiring test

People search for the best apromore Salesforce integration agency. Hand the partner a sample export of events, identifiers removed if you must, and the decision sentence. Ask what they would refuse to load. Ask which event they would drop as noise. Ask who in your team has to confirm the picture. Ask what lever they would simulate, and what they would not touch. Ask them to keep record migration off the fee.

A pass asks where the log comes from and whether off-system work exists. They name a filter. They name a lever you control. They refuse a field-map price. They refuse a revenue figure. They tell you the picture is useless until the queue has looked at it.

A fail arrives with a data loader and a weekend cutover. They promise a migration and a process saving in one number. They skip the person who works the queue. They call themselves the best agency. The export can go to someone else. The loader should not be pointed at this question.

Second test: they find a loop that surprises you. The pass is to go and ask the queue, not to recommend a tool in the same meeting. Surprise in a log is a hypothesis. The queue confirms it or kills it. A partner who skips that conversation is optimising a diagram.

#After the picture

Change one thing. Read the next log with the same definitions. If the wait moved, you have a result you can describe without borrowing anyone's percentage. If it did not, the lever was weak or the picture was wrong. Both are useful. Neither requires a second process, a new org, or a record load.

Write the result in the same event names you started with. If you rename a status between the two reads, you have broken the comparison and the second picture cannot be subtracted from the first. Keep a short note next to the log: the filter, the period, the lever, and whether the queue agreed the loop was real. That note is what a later quote should inherit. A fresh partner who re-extracts the same history without it will bill you to rediscover the noise. Store the note with the process owner, not in a slide that leaves with the project.

Keep the event definitions with the decision. The next team who asks for a quote should inherit the definitions, or they will rediscover the same noise and call it insight. Write the owner of the definitions. A log without an owner drifts the way a report without an owner drifts.

Automating the stall you find is a later choice, and only for the steps that are not already a fixed rule. Regrello, Agentforce, and Slack is that neighbouring quote. Do not let one partner sell the picture and the rebuild of every Flow as a single weekend.

Send the decision sentence and a sample of events. Ask which events they would drop. A partner who can answer, and who leaves the loader in the other toolbox, can price the extraction and the workshops. A partner who starts from the field map is answering a search term, not the work.

#The other searches

The project quote is on apromore implementation cost. That page does not print a figure. Who bought the company is on what happened to apromore. The connector is on integrating apromore with Salesforce. Whether to move is on should I migrate from apromore. The customer fee is on apromore licence cost. Who to hire is on hiring for apromore. This page does not rank an agency.