Should I migrate from ExactTarget

The journey left at nine. The person who owns it can name the send, the business unit, and the audience that entered. Around the table everyone already agrees that ExactTarget has to move, and the sheet in front of them has a blank column for a destination org and a weekend for a cutover. The agreement is the problem. It is easy to reach, and it fits several different explanations, only one of which a move would fix.

Painful naming is compatible with a journey that already runs in Marketing Cloud Engagement, a job that is not a send at all, a campaign on the core platform that records members and a status, and a rumour that Engagement is about to end. Only a job you can describe apart from the sends belongs anywhere else. The others arrive with you, under a new heading, with the same journey still leaving at nine.

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 person, a send, a business unit, a product. A general answer at this stage is what turns into a weekend later.

#1. Which send is actually in the room?

The question is not whether ExactTarget should be migrated. It is which send, in which business unit, to which audience, failed or succeeded this morning, and who would notice if it did not leave tomorrow.

A good answer sounds like the journey that left at nine, named by the person who owns it, with the business unit and the audience that entered, and a description of what a failed send looks like to that person.

A bad answer sounds like we need to move ExactTarget onto Salesforce. The sentence may be what the sheet says. It does not name a send, so nobody will be able to tell afterwards whether the weekend fixed anything. A programme with no checkable send cannot be judged to have succeeded.

Then ask the uncomfortable half. The word ExactTarget is still on old contracts, old exports, and old training titles. For email, mobile messaging, and journeys, the software those words point at is Marketing Cloud Engagement. The rebrand record says where the features sit, and the sentence is quoted once: "Email Studio, Mobile Messaging, Journey Builder, and legacy ExactTarget features were all consolidated under Marketing Cloud Engagement."

Read the names in that sentence. Email Studio, Mobile Messaging, Journey Builder, and legacy ExactTarget features were consolidated under Marketing Cloud Engagement. Consolidated under is a location. A glossary can keep the old word for the contract. The glossary is not a second system, and it is not a destination org. You are not moving ExactTarget onto a blank org. The sheet is asking for a move the account has not described.

#2. Does the send still belong in Marketing Cloud Engagement?

If the team will still run the journey in Engagement, on purpose, with no change of product, the decision for that journey is to leave it. Leaving it is a finished answer. A stay is allowed to be the majority of the list.

A good answer sounds like a named operator who will run that journey in Email Studio or Journey Builder for another year, and who can point at the business unit where it already runs.

A bad answer sounds like the brand is old, so the sends should move. Age of a name is not a destination. Marketing Cloud Next does not replace Engagement. A plan that moves every journey because a newer product exists has skipped the decision and copied a keyword onto a weekend.

Count the journeys you would leave running for another year with no change of product. Those rows are not a migration. The send that ran this morning is evidence the product is in use. Use the evidence. Do not argue with it from a search result.

There is no end date for Engagement in the material this decision is allowed to use. If a date is doing the work, the decision has not been made. Remove the date. A date can return only from a notice that is not in the record cited here. Until that notice exists, the date stays off the sheet.

#3. Is the remaining work actually a different job?

A job belongs in Marketing Cloud Next only when it can be written in one sentence that does not say the old brand is the reason. A send that still runs in Engagement is not that job. Putting both in one cutover because they share a meeting has turned a rename into a rebuild.

A good answer sounds like one sentence, written by a named owner, that describes the job, names Marketing Cloud Next, and gives a reason other than the ExactTarget brand.

A bad answer sounds like it is the new name. That sentence treats Next as the object Engagement becomes. Draw Engagement first. Draw Next only for a job already separated from the sends that still belong where they ran. No feature list for Next is invented here. The fact that changes the decision is the one already stated.

If you cannot write the reason, the job does not move. An empty list of jobs for Next is a valid outcome. Say so. The stays need no project. Keep three lines apart. Campaign: members and a status, on the core platform. Engagement: the studios and the journeys already named. Next: a separate product that does not replace Engagement. A plan that cannot keep the three lines apart is not ready. Send it back to the send name. There is no score, and there is no order of tools.

#4. What does a campaign already do, and what will an export not carry?

On the core platform, a campaign is a record. It groups campaign members. Each member has a status. The campaign records that a person was included in an effort and what status was written back, in that org. A contact is a person record. A lead is a person record that has not been converted. Those objects already do that work. They do it with no dependence on the ExactTarget name.

They do not run a journey. They do not hold Email Studio. They do not send a mobile message from Mobile Messaging. A campaign member status is a value on a core record. A subscriber entering Journey Builder is an event in Marketing Cloud Engagement. If the comparison starts from the campaign, keep those limits in view before anyone compares anything.

A good answer sounds like an administrator who has opened the campaign, named the member statuses, and said plainly that the journey which left at nine is not among them.

A bad answer sounds like we will export every data extension into a core object. Ask which send, after the export, no longer runs in Engagement, and why. If the answer is silence, the export is a copy, and a copy is not a decision. Loading members onto a campaign and calling the load a migration drops the journey. The member list can still help a sales team record who was included. It is not the send.

Native, for this decision, means the product the tools were consolidated under. It does not mean whatever object a core administrator can see after a sandbox refresh. The sandbox view is the core platform. The sends are in Engagement.

#5. What is the plan using instead of a send?

Three substitutes show up on the sheet, and each one is a way of not answering the earlier questions.

A Salesforce sandbox does not clone Marketing Cloud. A refreshed sandbox can hold leads, contacts, and campaigns from the core platform. It does not hold Email Studio. It does not replay the journey that left at nine. Anyone who treats the sandbox as a copy of ExactTarget is deciding from the wrong system. Open Engagement when you need to see the send. If the test of the migration is a sandbox refresh, reject that test. The send is observed in Engagement, or it is not observed.

A good answer sounds like a refusal, written on the sheet by a named person, of three things: an end date for Engagement, a sandbox refresh as the test, and an AppExchange listing as the destination.

A bad answer sounds like the listing, the sandbox, or the date will sort it. No listing is invented here. An app, a publisher, a review count, and a price are not in the record being cited, and describing them would be an invention. A listing found independently is still not the decision. The decision remains the send, Engagement, and whether any separate job belongs in Marketing Cloud Next. An app does not know which journey ran at nine. Engagement was not given an end date, so do not treat it as a retired product that a listing must replace. An AppExchange search will not bring a retired product back, and Engagement is not that case.

Other email and journey tools exist. They are not ranked here, and they are not put in an order. A destination that is only a score is not a destination. Choose a tool only when the send is named and the reason can be read without a score attached. If a slide arrives with ranks, replace the ranks with the send name and the mark before the slide is discussed.

#What staying actually looks like

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

State it. Staying means the journey keeps leaving at nine from Marketing Cloud Engagement, operated by the person who already owns the business unit. The word ExactTarget remains on the old contract and the old export. That is a real inconvenience for anyone searching the old brand, and it is not a broken send. The cost of a false move is a cutover whose destination column is still blank, run against a sandbox that does not hold Email Studio, with Marketing Cloud Next asked to become a product it does not replace.

There is a version of staying that is simply the correct decision. If the send still belongs in Engagement, and no separate job can be described without the old brand, then those are the facts, they are cheaper to leave where they stand, and a migration would have to rediscover them on the far side. An organisation that marks the stays first reaches any later job with a shorter list.

A good answer sounds like a stated list of stays, with the journey named, and a stated list of jobs for Next that may be empty, written by the operator rather than by the person who drew the weekend.

A bad answer sounds like we cannot keep calling it ExactTarget. The contracts may need a glossary. The send does not.

#Where the neighbouring questions live

What it costs to change a send you have actually named sits on the ExactTarget implementation page. The purchase, the owner, and the history of the name sit on what happened to ExactTarget. The connector, and what you do when a journey does not fire, sits on integrating ExactTarget with Salesforce.