Migrating From Adobe Campaign to Bloomreach: What Transfers, What Doesn’t, and How To Decide

If you run Adobe Campaign Classic v7, you’ve probably already had the conversation: Adobe is steering customers toward Campaign v8 or Journey Optimizer. Your integration partner has likely scoped the work and attached a cost to the shift. 

But there’s a crucial bit that often gets skipped in that conversation. Whether you move to v8 or evaluate the broader market, you’re rebuilding. And once you accept that, the question shifts from “Should we migrate?” to “What should we rebuild into?”

You should also consider the opportunity cost beyond the scoping document: the campaigns your team hasn’t prioritized because the effort to build them was too high, the personalization that stayed on the roadmap because it required developer involvement, or the reporting cadence that could be faster with a different toolset. Those costs are harder to quantify, but they belong in the business case.

This is a practical guide to answering the “What should we rebuild into?” question, including the cases where the answer is to stay put.

The Decision You’re Actually Making

There’s some confusion about when v7 support actually ends — while some sources say support will end in March 2027, Adobe maintains its own compatibility and lifecycle matrix for Campaign Classic, and extended support arrangements beyond standard support are available at additional cost. Your own agreement with Adobe is the only authoritative answer, so check it rather than trusting any public date.

Regardless of the actual transition date, the important takeaway here is that Adobe is transitioning away from v7 and moving customers to v8 and Journey Optimizer. This direction changes the economics of inaction. Normally, “do nothing” is the cheapest option on the table, which is why so many marketing teams stay on tools they’ve outgrown. Here, doing nothing has an expiry date attached. You will spend the reimplementation effort — the only variable is what you get at the end of it.

So, the real framing here is a comparison of two rebuilds, not a comparison of a rebuild against the status quo.

If you’re on Campaign Standard rather than Classic, the same logic applies and usually sooner. Adobe has been moving Standard customers onto other products for a while, so that cohort is choosing between Classic, v8, and Journey Optimizer, all of which are new implementations. Everything below applies to that decision too.

What Moving to v8 Actually Involves

Let’s go deeper into what moving to v8 actually entails. The information in this section is sourced from Adobe’s transition documentation, which was last updated in May 2026. Here’s what you need to know: 

• v8 is a Managed Cloud Service only. It “can’t be deployed on an on-premise or hybrid environment.” If you run v7 in an on-premise or hybrid environment today, your hosting model will change.
• There is no automated migration. Adobe states that “automated migration from an existing Campaign Classic v7 environment is not yet available.”
• The data architecture is different. In its enterprise (FFDA) deployment, v8 works with two databases: a local Campaign database for the interface, real-time messaging, and unitary queries, as well as a cloud Snowflake database for campaign execution and batch queries.
• All deliveries route through mid-sourcing. v8 relies on a hybrid architecture in which internal routing is not possible, and the external account is disabled accordingly. Delivery status updates are no longer instant; a technical process on the marketing instance updates them.
• Some capabilities are not carried forward. Adobe lists the v7 features unavailable in v8 in the same transition document, and maintains a separate list of deprecated and removed Campaign Classic features. Check both against what your team actually uses.

Something else to consider if you run v7 on-premise or hybrid is the patch cycle. Platform providers regularly release updates that apply to fully on-premise deployments and the on-premise components of hybrid environments. While cloud-hosted instances are typically remediated by the provider with no customer action required, on-premise and hybrid customers must manage these updates themselves.

What’s of note here is who carries the operational load. On-premise deployment means your team owns the upgrade cadence, and the hosting model is precisely what changes on the v8 path. Whichever way you go, that load belongs next to the migration numbers rather than in a separate conversation with IT.

If your team writes directly to the Campaign database today, that pattern is the one to look at first. It’s the change most likely to turn a version upgrade into a data engineering project.

None of this makes v8 a bad product. What it does mean is that the scope of a v8 move is closer to a new implementation than a conventional upgrade, which is a materially different thing to budget for.

What Transfers to Bloomreach and What Doesn’t

Moving to v8 is not your only option, though. If you’re evaluating alternatives, here’s what transfers and what doesn’t — because more carries over than most teams expect:

The warehouse work transfers. Because v8 pushes campaign execution onto Snowflake, a lot of v7 shops are already being pushed into warehouse-centred data modeling: getting customer, event, and catalog data into clean, queryable tables. That work isn’t Adobe-specific, and it’s not sunk cost if you choose us. We connect to Snowflake natively as a data source for customers, events, and catalogs. Once configured, the integration imports from tables, views, or user-defined queries, and with CHANGE_TRACKING enabled on the source table, it runs delta syncs as often as every 15 minutes. Your warehouse stays your source of truth.

That is the single most important thing to understand about the decision. The most resource-intensive part of any migration — the data engineering — is also the part that’s portable.

Just keep in mind that a warehouse is a source, not a shortcut. Teams with data already centralized in Snowflake or BigQuery often assume migration collapses to “point the new platform at the warehouse and go,” and it does not: 

• Structure still has to be mapped to how we store customer records and events
• Identity resolution still has to be decided because the IDs your warehouse keys on may not be the IDs that pair your events correctly
• Consent records still have to be carried across with their history intact
• Historical events still have to be formatted correctly, in the right order, before any of it is useful for segmentation 

Having the warehouse means the raw material exists and is clean, which is a large head start. However, it doesn’t mean the work is done.

The data modeling gets looser on the way in. Our platform is not a relational database. Data is stored in a NoSQL structure as customer records with extensible attributes and an event stream attached, and schemas are not checked or validated on ingestion. New attributes can be added at any time afterward through the data manager or an import. If the v8 exercise in front of you involves committing to a fixed data model before you know what you’ll need, that constraint is worth pricing in.

The trade-off here is that Campaign’s relational model enforces integrity at the database level, and ours does not: data needs to be clean, flat, and enriched at the point of ingestion, and events are immutable once stored. If you run relational structures today, with linked tables and referential integrity you depend on, that’s a rethink rather than a lift-and-shift. Teams in that position should scope this specifically before deciding anything.

Templates do not transfer, and nothing will change that. This is one of the most common assumptions going in, but templates are not portable files that export from one platform and import into another. You can export HTML, but HTML doesn’t translate back into an editable drag-and-drop template at the other end, in our platform or anyone else’s. Campaign’s delivery templates and personalization logic get rebuilt. We use Jinja for personalization, which business users can generally edit without a developer, and reusable blocks make the rebuild faster than starting from nothing, but it is still a rebuild. Treat it as the moment to retire templates you’ve been carrying for years rather than faithfully reproducing them.

Integrations have to be repointed either way. Every data feed, every downstream system, and every API consumer needs attention in any migration. The effort is comparable regardless of which platform you choose.

What Your Marketing Team Actually Gets

The section above is written for whoever owns your data architecture. This one is for the people who will open the platform every morning because they’re the ones who live with the decision longest and are usually the last to be asked.

Start from how the work is done today. Adobe documents Campaign Classic as a client console that marketers launch and connect to your application servers. That architecture is the thing your team’s daily experience is built on, and it’s what a v8 move carries forward since v8 keeps the familiar interface. Here’s what the Bloomreach environment looks like for marketing teams: 

Campaign work is self-serve. Segmentation, journey orchestration, A/B testing, and reporting are designed for marketers to run without filing an engineering ticket. This is the operating-model shift the whole exercise is about, and it’s the one that keeps paying every week after go-live rather than only at launch.

Personalization runs on three kinds of AI. Rules-based logic gives you control and keeps a message away from a customer who didn’t consent. Machine learning gives you precision on the predictions that matter, like churn risk and send time. Generative AI writes copy and turns a described objective into a built campaign.

The customer view is unified by design. Email, SMS, push, web, and mobile all read from one customer record with one event stream, so a behavior on the site is available to the next message without a sync job between systems.

One caveat to call out: Personalization uses Jinja, not a visual drag-and-drop logic builder. Business users can generally edit it directly, and for complex conditional content someone on your team can pick up some syntax. It’s learnable, and most teams get comfortable with it quickly, but you should know that going in rather than meet it in week two.

Keeping the Adobe Stack You’re Not Replacing

Remember: Replacing Campaign is not the same decision as replacing Adobe as a whole.

Plenty of teams run Experience Manager for content, Analytics for reporting, and Experience Platform for enterprise data, and have no intention of moving off any of it. Those investments are separate from the Campaign question. Loomi is designed to sit alongside them, ingesting data through imports and APIs or directly from the warehouse those systems already feed, and there’s a documented path for wiring up systems we don’t ship a connector for via custom integrations.

In your conversations with us, ask us to map your specific Adobe components against how data would actually flow. It’s a short exercise, and it’s the fastest way to find out whether coexistence is actually straightforward in your setup.

If you’re being asked internally whether this means “ripping out Adobe,” the answer is no. It means changing which system orchestrates and sends your customer communications, while the rest of your stack keeps doing what it does.

What Actually Decides Whether This Goes Well

The generic mechanics of an ESP migration are covered in our ESP migration guide, which walks through discovery, goal-setting, integration mapping, and launch across six phases. Rather than repeat that, here are the areas where Adobe Campaign migrations specifically succeed or fail.

Deliverability Continuity

Deliverability is a major concern that stops most migrations, and it should be taken seriously. Your sending reputation is attached to your current IPs and domain authentication.

The mechanism that protects it is a structured warm-up. Our documentation sets out how this works: warm-up applies when you start sending from a new IP or domain, or increase regular volume by more than 25 to 30%, and it doesn’t apply if you’re simply adding an IP to an existing pool. One of our consultants builds a plan broken down by the mailbox providers your customers actually use, following sender guidelines from Gmail, Yahoo, and Microsoft. A typical ramp starts around 1,300 emails on day one, holds, then roughly doubles: 1,300, then 2,600, 5,500, 11,000, etc. You start with new and active users, then expand to passive and lapsed segments once reputation is established.

There are a couple of things to keep in mind here. First, past engagement data needs to be imported before warm-up begins, because segmenting by engagement is what makes the early sends safe. Second, you keep sending on Adobe while this happens — the overlap is the point.

A great migration example for reference is FitFlop. Our email specialists built a joint execution plan that maintained continuity for every subscriber, including transactional sends, with no disruption to communications during the switch. As a result, inbox placement improved 10% afterward, and the brand delivered an additional 15 million emails.

Data Import Discipline

Migrations rarely fail on the platform — they fail on the data, and usually in the same few ways. Our import best practices outline them:

• Import the oldest events first. If something goes wrong, event expiration in the data manager lets you strip the newer data back out rather than starting over
• Convert every timestamp to a UNIX timestamp or ISO datetime. Regional date formats are the classic example of silent corruption: “02/04/2017” is April in one locale and February in another
• Keep customer IDs consistent, trimmed, and lowercased. Misspelled IDs create duplicate profiles, and the platform pairs events by whichever mapped ID is available
• Know the limits before you plan the sequence. A single import can’t exceed 1,000,000 rows or 1 GB, so large historical loads need to be split
• Test in a test project first. Accidental deletion or duplication is much cheaper to discover before production

If you’re migrating years of engagement history, this list is the difference between a two-month project and a six-month one.

Double Run Instead of Cutting Over Cold

A common concern about migration is picturing it as lights-off, lights-on: marketing goes dark for a week while systems swap. In practice, migrations run as a parallel process, and the risk is more manageable than it first appears.

There’s no limit on the number of projects in an account, and projects are fully isolated environments sharing no data. Teams use them for development, staging, and production, and multi-brand or multi-market customers use them to keep separate customer bases apart.

For a migration, that means you build and validate the new implementation without touching anything live, then double-run: both systems send, side by side, so you can compare real performance before committing to anything. Campaigns move across one at a time. Adobe keeps sending until you’re satisfied it shouldn’t, and go live becomes a series of small decisions rather than one big one.

This is also your rollback plan. Because the old platform is still live and capable throughout the process, a problem during the transition means pausing and reverting to Adobe for the affected campaigns while you diagnose. If deliverability on a warmed segment looks wrong, you slow the ramp. If an import turns out to be malformed, event expiration lets you strip the bad data and reload. Nothing about the sequence requires a point of no return until you choose one.

You’ll also want to develop consent synchronization during the double-run: If someone unsubscribes on Adobe while both systems are live, that has to reach us, and vice versa. Consent in our platform is stored as timestamped events on the customer profile with a full auditable history of who changed what, when, and from where. Consent can be written through the API or a scenario, so keeping the two aligned is buildable. It’s an integration you scope up front, not a checkbox. 

Who Does What, and How Much Lands on Your Team?

A migration is not something done to you while you watch, and any vendor implying otherwise is setting you up for a surprise in week three. Here’s a breakdown of where responsibilities should land:

What we do. A consultant builds the warm-up plan against your sending profile, broken down by the mailbox providers your customers actually use, and reviews and approves it with you before anything sends. Email specialists work the deliverability side through the ramp-up. The implementation checklist covering subdomain setup, DNS, DKIM, MX, and DMARC records — as well as the decision around shared or dedicated IP — is walked through with you during onboarding rather than handed over as homework.

What your team owns. Your team decides which use cases move first and which get retired, which is a commercial judgement nobody outside your business can make for you. You’ll also need to supply and sanity-check the data, including the customer IDs and the engagement history that the early warm-up sends depend on; rebuild the templates and journeys you’ve chosen to keep; and sign off on the double-run comparison.

Where you’ll need technical resources. You’ll want technical resources for the initial data integration, the identity decisions described above, and repointing whatever currently writes into Campaign. If your v7 setup writes directly to the database, budget properly for this part. Day-to-day campaign work afterward is self-serve, and that shift is the point of the exercise, but the integration at the front is engineering work.

The heaviest weeks for your team are the data preparation at the start and the validation during the double run. If your team is already stretched (and most are), say so early and scope against it rather than discovering it mid-project. A migration scoped around a team’s real capacity beats an ambitious one that stalls.

Online pharmacy etabletka illustrates the power of a properly prepared transition. The brand’s customers depend on timely access to medicines, which means it couldn’t pause any of its communications. The migration had to preserve historical data, maintain reporting continuity, and keep automated campaigns running throughout. With the help of our team and processes, etabletka was able to complete a full switchover in only two months with zero communication downtime. 

Set a Target Before You Start, Not After

Before any migration, one thing you should do is write down what you’re trying to beat. Teams that migrate without a baseline end up unable to tell whether the new platform helped, and that ambiguity is how a successful project still gets remembered as a disappointment.

It’s worth benchmarking your current engagement metrics against industry standards before you scope anything. If engagement has drifted down over a few quarters and the working theory is channel fatigue or list quality, a benchmark comparison is a low-cost way to test that theory. It may confirm what you already believe, or it may surface opportunities that aren’t visible from inside a single platform — and that belongs in the business case regardless of which direction you go.

We’ve published marketing benchmarks built from real sends across our customer base, covering 15 metrics and 16 industries. For reference, the averages across all industries are 98.4% for email delivery, 42.7% for unique open rate, and 3.3% for unique click rate. 

There’s also a scoring tool that takes your current metrics and compares them against those benchmarks. Running your Adobe Campaign numbers through it before you scope anything gives you the baseline your business case needs, no matter which platform you end up choosing.

Do that before you settle on an explanation. If engagement has drifted down for a few quarters and the working theory is channel fatigue or list quality, a benchmark row is a cheap way to test that theory before a migration business case gets built on top of it. It may confirm what you already believe, or it may tell you that the ceiling you’ve been hitting is structural, and that belongs in the business case rather than in a separate conversation about creative.

How To Decide, Including When To Stay

So, how do you decide whether a new platform or sticking with Adobe Campaign is right for your brand? Here are some factors to consider. 

Moving to v8 is probably right if your Campaign implementation does what you need, your personalization requirements are largely campaign-based rather than real-time, and your organization is deeply invested in the wider Adobe ecosystem. A long-standing implementation partner who knows your instance, a team fluent in Campaign’s data model, and an established governance and procurement relationship are real assets. Rebuilding on v8 doesn’t make them worthless, and rebuilding elsewhere means rebuilding some of them too. If your evaluation of v8 accounts for the architectural changes described above and still comes out positive, then that might be the best option for you.

Evaluating alternatives is probably right if any of the following are true: you’re already redesigning data ingestion because direct database writes break, you depend on capabilities not carried forward into v8, your team needs to build and ship campaigns without waiting on developer availability for routine work, or the v8 project timeline your partner quoted is longer than your team can accommodate given other priorities.

There’s a second test you should also run alongside the first, and it’s the one your CMO will care about most. Ask: after the migration, will our marketing team be able to do things they cannot do today? Not incrementally better versions of the same campaigns, but fundamentally new capabilities. That question applies equally to v8 and to any alternative, and you should answer this honestly before committing the budget.

Ultimately, you’ll want to look at the operating model, not features. Ask: after the v8 migration, can your marketing team build and ship a campaign without a developer? Then write down what they’ll be able to do that they can’t today. Almost every other comparison folds into that first question, because the operating model — how much your team can do without specialist support — is a cost that runs for as long as you own the platform, and it doesn’t appear on any license.

Additionally, continuity and capability are both legitimate things to buy, but they’re different purchases, and they get conflated at exactly the moment someone has to justify the number. If you find that the team will be doing what it does now on newer infrastructure, write it up as continuity and price it accordingly. If the answer is that they’ll be doing things the current stack can’t do at all, that’s a different paper with a different sponsor and a different approval route. Deciding which one you’re writing before you start saves you from the version that tries to be both and convinces nobody.

Whichever way it goes, timing is the thing people underestimate. Enterprise migrations of this size run for months, and the decision window closes well before the support date does because committing to a v8 project commits the budget and the team. Our ESP renewal calendar covers how to work backward from that. 

Talk to Us Before You Scope the v8 Project

If you’re building a v7 migration business case right now, we’ll compare the two paths with you properly, using a realistic assessment of migration effort rather than an optimistic one. That conversation is most useful before your integration partner finalizes the v8 scope, because the data architecture decisions taken at that point are the hardest ones to revisit.

Here’s how you can approach this, depending on which seat you’re sitting in:

If you’re scoping the migration, bring the scoping document. We’ll go through it with you and tell you which parts transfer, which parts get rebuilt, and where our estimate of the effort differs from the one in front of you.

If you run CRM or lifecycle, the useful question is what next quarter looks like for your team, not what the architecture diagram looks like. See what your Campaign use cases become in our marketing automation, including the prebuilt use cases you would start from rather than build from nothing. Schedule a personalized demo and bring two campaigns you find painful to run today.

If you’re writing the business case, ask us for the side-by-side: the v8 path and this one, what each needs from your team, and where the effort actually lands. Bring the timeline you’ve been given, and we’ll tell you which parts of it look optimistic to us, including the parts that are ours.