Adobe Campaign Partners

What each version commits you to

Campaign Classic, now generally referred to as v7, is the long-established on-premise or hosted product with a desktop client, deep customisation of the data model and the technical workflow engine that most complex estates were built on. Campaign Standard is the cloud-native successor with a browser interface, a more constrained data model and considerably less scope for bespoke logic. Campaign v8 brings the Classic capability set onto a cloud architecture with a Snowflake-based data layer, changing how the large tables behave and what the platform can handle at volume.

The version determines what skills you need and what is even possible. Deep Classic work means people who can write technical workflows, understand the schema extension model and reason about database performance. Standard work is closer to configuration with defined integration points. A v8 migration is a distinct program with its own data model considerations rather than an upgrade in the ordinary sense. Establish which version you are on and where you intend to be before scoping anything, because a proposal written for the wrong one will be wrong throughout.

Signals that tell you what you are dealing with

• Count the technical workflows — an instance with hundreds, many failing or paused, is carrying real debt regardless of version.
• Look at schema extensions — heavy customisation of the recipient table is powerful and is also what makes upgrades expensive.
• Check the delivery volumes against the sending infrastructure — capacity problems in Campaign usually appear as overnight delays, not errors.
• Find the undocumented dependencies — scripts in workflows that call external systems are the usual cause of mysterious failures.
• Ask when the last upgrade happened — a long-deferred version is a cost that accrues quietly until support becomes the forcing function.

Auditing what is actually running

Before any change, get an inventory of the technical workflows with, for each one, its schedule, its last successful execution, its typical runtime, what it reads and writes, and whether any human would notice if it stopped. In inherited estates a meaningful share of workflows turn out to be duplicates, abandoned experiments or processes kept alive because nobody was confident enough to switch them off. Each of them consumes database resources and adds a place where a change can break something unexpectedly.

The same applies to the data model. Custom fields added over the years to the recipient schema accumulate, and many are populated by a workflow that stopped running long ago. Ask for a population and freshness check across custom fields, because targeting logic that filters on a field last updated in a previous year produces confidently wrong audiences with no error anywhere. This audit is unglamorous and it is usually the highest-value thing anyone can do to an established instance.

Where the fragility concentrates

• Workflows without error handling — a failed step that silently stops leaves an audience half-processed and a campaign partially sent.
• Overlapping schedules — long-running jobs colliding on the same tables cause lock contention that looks like random slowness.
• Staging tables never cleaned — working tables that grow without a purge routine degrade the whole instance over time.
• Hardcoded values in scripts — credentials, file paths and identifiers embedded in workflow code break on any environment change.
• No separation between environments — testing against production data because the staging instance drifted is a common and dangerous shortcut.

ETL and CRM synchronisation

Campaign almost always sits at the end of a data supply chain: customer records arrive from a CRM or warehouse, transactional data from operational systems, and consent state from wherever preferences are captured. The reliability of every campaign depends on those feeds, yet ownership of them is frequently ambiguous. The marketing side assumes the data team guarantees them, the data team assumes Campaign will cope with whatever arrives, and nobody monitors whether the file landed this morning.

Settle ownership explicitly for each feed: who produces it, what the contract is in terms of schema and timing, who is alerted when it fails, and what Campaign does when data is missing rather than wrong. A workflow that proceeds with yesterday's file because today's did not arrive will send a campaign to a stale audience without complaint. Ask whether the import workflows validate record counts against an expected range and halt on anomalies, because that single control prevents a large share of the incidents that damage trust in the platform.

Consent and preference as a data problem

Consent state is the feed that must never be wrong. In most estates preferences can be changed in several places: a preference center, a call center system, an unsubscribe link and sometimes the CRM directly. If those paths do not converge into a single authoritative state in Campaign within a predictable window, you will eventually mail someone who opted out, which is both a regulatory problem and an avoidable one.

Ask to see the synchronisation path for every place a preference can change, including the latency of each, and ask what the reconciliation process is. A periodic comparison between Campaign's subscription state and the source of truth, with a report of discrepancies, is a modest piece of work that prevents a serious category of failure. Confirm too that suppression applies across all deliveries rather than being implemented per-campaign, which is a surprisingly common gap in estates that grew organically.

Deliverability configuration and reputation repair

Campaign gives you direct control over the sending configuration: affinities that route deliveries across sending addresses, throughput settings per mailbox provider, retry behavior for temporary failures and the rules that determine when an address is quarantined. Used well, this control is an advantage over simpler platforms. Left at defaults in an estate that has grown, it produces uneven placement that nobody can explain, because the aggregate delivery rate looks fine while one major provider is quietly filtering everything.

If you are already in trouble, reputation repair is a defined sequence rather than a setting to change. It means stopping sends to long-term unengaged recipients, tightening quarantine rules, verifying authentication on every sending domain, checking whether any address appears on a blocklist and then rebuilding volume gradually against engaged recipients. It takes weeks and it requires accepting lower volume during the recovery. Any proposal that offers to fix deliverability without reducing sending volume to disengaged addresses has not understood the problem.

What managed campaign operations should deliver

• A defined build and approval path — how a brief becomes a tested delivery, including who signs off the audience before send.
• Proof and rendering checks — verification across the mailbox clients your audience actually uses, not a single desktop preview.
• Audience counts before every send — a count that differs sharply from the previous run should stop the send, not be noticed afterwards.
• Per-provider reporting in the quality report — placement, bounce and complaint rates broken down, with a comment on anything that moved.
• Workflow health in the same report — failed and overdue technical workflows listed, since they are the usual root cause of campaign issues.

Programs rarely stop at one product. Buyers hiring for Adobe Campaign often pair it with Adobe Analytics partners , Adobe Brand Visibility partners or Adobe Commerce partners , or review the whole Adobe landscape before committing.