Should you migrate from MuleSoft?

A steering note on Thursday said the integration platform was finished. MuleSoft would be migrated into Salesforce, and Flow would replace it. The note cited a Data Cloud rename from October 2025 and treated that rename as the cutover. Around the table everyone already agreed. On Friday the runtime was still carrying orders, because nobody had a replacement for the message. On Monday another team switched a subset off anyway. The warehouse call stopped. Sellers typed orders by hand. By Wednesday there were two orders for one shipment, and a sandbox refresh had not brought the runtime back. The agreement is the problem. It is easy to reach, and it fits a slide that ran out of boxes, which is not a message anyone can name.

A failed order is compatible with a runtime that still needs its own queue, a Flow that already updates a field inside the org, a Data 360 label that does not carry an order, and a sandbox that copied Salesforce metadata and did not replay yesterday's messages. Only one of those is a decision about a named message. The others travel with you if you switch the runtime off first. The 2018 acquisition had been used as a reason to move a product. The product had not moved. The orders had.

What follows are the questions that separate those explanations. Each has a good answer and a bad answer, and the difference is whether the answer names something specific: a message, a system, an object, a person who owns the queue. A general answer at this stage is what turns into a hand-typed order.

#1. Which message is actually in the room?

The question is not whether to migrate MuleSoft. It is which message a seller can recognise, which system owns it today, and what that seller does on the morning it fails.

A good answer sounds like one message, such as the warehouse status on the order, named by the team that uses that name, with the field the seller already reads and the person who owns the queue.

A bad answer sounds like migrate MuleSoft. The sentence may be the steering note. It does not name a message, so nobody will be able to tell afterwards whether Wednesday's double order was fixed. A programme with no checkable message cannot be judged to have succeeded.

MuleSoft was acquired in 2018 and kept its name. It is an integration platform. Agreed messages move. A failure can be held and tried again by a person who owns that queue. Salesforce can be the place a seller reads a subset of the result. The other system can remain the system of record. The product did not become a CRM. It did not become a report. It did not become a backup of the org. The name on the contract is still the name you use in the meeting. Keeping the name in 2018 means you still ask for MuleSoft by that name when the message crosses a boundary. 2018 is a date. It is not a destination.

#2. Does the message still need a runtime of its own?

Stay when those messages still need a runtime of their own. The runtime sits outside the org. It has an owner. It has a place a missed message waits. It has a way to try again that does not create a second order. Flow can update a record. That fact does not turn Flow into the runtime. The acquisition did not fold the runtime into the org.

A good answer sounds like a named owner who will keep the runtime for messages that cross a boundary, and who can say what happens to a message that arrives while the source is down.

A bad answer sounds like we will switch the runtime off and let Flow carry the warehouse. You are not replacing MuleSoft with a Flow. A Flow that tries to become the warehouse will call a system it does not own, on credentials nobody wrote down, or it will wait for a person to type the status. Both can be chosen on purpose. Neither is a migration of MuleSoft into the CRM. A programme that starts by switching the runtime off has chosen the outage. Send that programme back before anyone calls it a walkthrough.

Move one message only after you have written where it will live, which object it may touch, and what the seller does on the morning it fails. Moving "the warehouse status onto the order, in the field the seller already reads" might be that sentence, if that field has an owner. Moving "MuleSoft" is not.

#3. What does Flow already do?

Name the native behaviour before you compare anything to it. A Flow is automation inside the Salesforce org. It can start when a record is created or when a field changes. It can create or update a record in that same org. It can send an email, or act as a user the org already controls, under the limits that org already enforces. An administrator can open it in the org that owns it. A sandbox can contain that Flow, because a sandbox copies Salesforce metadata. That is what the native automation already does. It runs where the records live.

Flow already updates records the running user is allowed to update. It already reacts to changes inside the org. It already has an owner who can deactivate it. It does not already contain the warehouse. It does not already hold yesterday's messages from a system the sandbox never copied. It does not already keep a queue for a source that was down before the seller arrived. Those are not checkboxes on the Flow. They are a different place for the work.

A good answer sounds like four lines from an administrator who opened the Flow: which object starts it, which fields it may change, which user it runs as, and what a seller sees when it stops. A Flow that sets a stage and a date on one opportunity is a fair example, because a person can see the result on that record.

A bad answer sounds like Flow can integrate anything, or replace it with Flow. If you cannot answer the four lines, you do not yet have a native feature to stand beside MuleSoft. You have the word Flow. If the problem is "when the opportunity reaches this stage, fill three fields on the same record", you may not be migrating at all. Write the three fields. If the Flow already writes them, leave MuleSoft out of that sentence. Calling that a migration inflates a field update into a platform move.

#4. Why is Data 360 on the diagram?

People who search for what the software is now often land beside Data 360, because both names sit near the word data. They are different products. The help page states a rename, and the sentence is quoted once: "As of October 14, 2025, Data Cloud has been rebranded to Data 360."

Use that sentence to correct a label on a diagram. It does not mention MuleSoft. It does not say an integration flow became a Data 360 pipeline. It does not revise the 2018 deal. On 14 October 2025 the product formerly called Data Cloud took the name Data 360. Put the rename on the Data 360 line. Leave MuleSoft on the 2018 line, with the name it kept.

A good answer sounds like two lines on the diagram, written by the person who cited October 2025: Data 360 renamed on 14 October 2025, MuleSoft still the 2018 integration platform.

A bad answer sounds like the rename is the cutover. A renamed data product is not an order message. Do not move the runtime into Data 360 because the cited sentence changed a label. The sentence is the rename. The late order is still a message with an owner. Keep that owner off the Data 360 box unless a different decision gives Data 360 a job that is not this message. Data 360 is not MuleSoft, and it is not Flow.

There is no end date for MuleSoft in the material this decision is allowed to use. Do not invent a shutdown. A rename of Data Cloud is not a retirement of MuleSoft. An acquisition that kept the name is not a sunset. If a vendor tells you to switch the runtime off because the company was bought, ask for a retirement notice that names MuleSoft and names a date. A slide that cites October 2025 does not qualify. Until a notice like that exists, the software is the integration platform it was. Buying Salesforce does not turn the runtime on. If the contract is silent about the runtime, the runtime is a separate question. That question is not closed here with a fee.

#5. What is the plan using instead of the message?

A Salesforce sandbox does not clone MuleSoft. Refreshing it copies Salesforce metadata and, depending on the type, some CRM data. It does not copy the runtime. It does not replay yesterday's messages. Anyone who says the refresh included MuleSoft should open the sandbox and show the flow. The absence is the finding. A spreadsheet load is not a migration off MuleSoft. It is a paste, and it goes stale. Replacing the runtime with a Flow you have not opened is a hope, not a decision. Open the Flow. If its fields are not the warehouse status, keep MuleSoft for that status.

A good answer sounds like a refusal, written by the person who typed the order by hand, of four things: a sandbox as a clone of the runtime, an end date, an AppExchange listing as the queue, and a ranked shortlist.

A bad answer sounds like the listing, the refresh, or the acquisition will replace the runtime. No listing is invented here. An app you have not installed is not described. A listing does not replace the runtime. A catalogue page is not the decision. If a proposal cites a listing that was never named here, ask them to open it and read what it actually does to one message. Until they can, the listing is a rumour. The shapes that will be named are not ranked. Stay on MuleSoft for messages that cross a boundary. Use Flow for a change that starts and ends on records inside the org, after you have named the object and the fields. Keep both, with two sentences a seller can tell apart. A shortlist with a winner is a ranking. Firms are not ranked. Listings are not ranked. Two options that both name the same message can be compared by what the seller does on a failed morning. A league table cannot tell you that. The 2018 acquisition kept the MuleSoft name. It did not produce a ranked replacement.

Keep the choice to one message. The next message is the next decision. A list of every system in the company is a poster. Cross out the systems this decision will not touch. Read the choice to the person who typed the order by hand. If they cannot see their morning in it, rewrite it until an order number would fit.

#What staying actually looks like

All five answers are measured against an alternative, and the alternative is usually left unstated, which flatters the switch-off.

State it. Staying means the runtime keeps the message that crosses a boundary, with an owner and a place a missed message waits, and Flow keeps only the change that already lives on a record inside the org. The cost of a false move is the week you already had: the warehouse call stopped, sellers typed orders, and one shipment became two orders, while a sandbox refresh did not bring the runtime back.

There is a version of staying that is simply the correct decision. If the gap after Flow is still the outside message, the runtime stays, and the status the seller needs is one field with an owner. An organisation that writes that field first reaches any later re-pointing with a shorter list and the runtime still carrying orders.

A good answer sounds like one message, what Flow already updates, the gap, and a choice of stay, Flow for that gap, or both, with a date and a person who will look again, produced by the queue owner rather than by the Thursday note.

A bad answer sounds like we cannot keep a product that was bought in 2018. The purchase kept the name. It did not move the runtime into a Flow.

#Where the neighbouring questions live

Cost and hiring sit on the MuleSoft implementation page. The purchase story sits on what happened to MuleSoft. The connector sits on integrating MuleSoft with Salesforce.