A migration utility can move technical objects, but it cannot redesign integrations, reconstruct undocumented business logic or prepare teams to operate in a new cloud ecosystem. As we explored in the first part of the article, understanding both capabilities and limitations of the tooling is essential. But it is only the starting point. The success of the wider migration depends on five interconnected areas, 5 pillars we now use to structure and evaluate every SAS MA-to-CI360 migration.
Here are the five areas we now treat as the real pillars of any migration.
You can't start any cloud-to-on-premises integration without installing and configuring the Direct Marketing Agent first. It sounds like a straightforward, one-afternoon task. In practice, it's rarely that simple.
First, versioning matters: the agent for SAS 9.4 M5–M7 requires Java 8, M8 requires Java 11, M9 requires Java 21 — and upgrading SAS 9.4 means a fresh agent install, not an in-place update. There's also a hard deadline: starting 15 July 2026, agents on SAS 9.4M7 or older can no longer connect to the CI360 API gateway at all.
Then there's network and access. The agent needs an outgoing WebSocket connection that many corporate firewalls block by default, plus specific user permissions: SASServer1 login rights, SASUSERS group membership, metadata read/write, and database access. In enterprise IT, that's several separate approval tickets before you've touched a single campaign.
Once installed, the agent isn't "set and forget." Its metadata commands must run in strict sequence, and the whole thing depends on an Information Map that has to exist before the agent is useful — which itself requires a configured business context.
The Information Map itself can be the same as you used in MA. However, in most of the projects, we update it to get rid of legacy data items and to add an actual ones, or even rebuild it from scratch to make it more manageable.
Versioning, network approvals, access rights, correct sequencing, Information Map configuring: get one wrong, and a "few hours" install becomes a multi-week IT ticket chain.
To actually use that on-premises connection, you need to set up several cloud-side entities:
Get all four right, and CI360 becomes as flexible as MA used to be. Get any one wrong, and you'll feel it downstream — which is exactly where the next problem shows up.
MA comes with a native on-premises database, and in most real deployments, that database quietly became the backbone for reporting and integrations well beyond marketing. CI360 doesn't give you that for free.
To preserve data access, you need to build a custom database to hold whatever cloud data must remain available locally. That means scheduling regular UDM downloads and configuring additional exports just to keep that custom database fed.
One detail is especially easy to miss if your existing communication channels use CDM attributes directly. In MA, many of those attribute IDs are numeric. In CI360, cloud-side attributes are UUID-based. If downstream systems, channel integrations, or reporting logic depend on those IDs, you need to design the one-to-one ID generation and mapping process very carefully. The mapping has to stay consistent between CI360, the replacement local database, and every integrated system that consumes the data. Otherwise, the migration can look successful in the cloud while silently breaking attribution, reporting, or channel execution downstream.
Out of the box, Direct Marketing Tasks just save exported data to an on-premises database for customers in the selected segments. No transformation, no validation, nothing fancy.
Real-world migrations rarely stay that simple. You'll need to validate inputs, split single fields into multiple columns to feed downstream integrations, or trigger another task mid-process. Every one of these requires a custom Post Process script.
You'll likely also need to push local segments back into CI360 — a global control group table is a common example — and that's another script, another piece of custom development that isn't in any migration utility.
None of these scripts are individually complex. But they're consistently required for any enterprise-grade integration, and none of them show up in the "automated migration" pitch.
MA's integrations feed data to delivery systems, reporting tools, CRM platforms, and everywhere else the business depends on customer data. They rely on on-premises scripts and the CDM's storage structure to do it. CI360 has no on-premises footprint beyond the Direct Agent itself, which means every one of those integrations has to be updated or rebuilt manually.
We already covered CDM replacement above, but the integration scripts themselves take their own chunk of time. In the best case, that's just repointing a connection string to a new source database. In the worst case, it's rebuilding the integration logic entirely to handle a new data structure at the source.
Either way, "migration" ends up meaning something closer to "re-engineering", one integration at a time.
Migration doesn't have to stop at rebuilding the same on-premises integrations you had in MA. In most cases, it's worth partially migrating channels onto CI360's native rails instead, which frees you to use CI360 more fully and gives you access to the newest features SAS ships.
Email is the clearest example: CI360 lets you save email parts as creatives, build the final email body in a drag-and-drop editor, and personalize using Information Map or Data Hub data items, among other features.
On-premises integration is more flexible, but it comes with an ongoing maintenance cost. Before migrating, it's worth deciding, channel by channel, whether to rebuild the on-premises integration or move to native.
Information Map update deserve its own scope. Even migrating it as-is from MA, issues like network connectivity or source database access will cost you a day or two. Update the Map, and generation issues can add a week on top of the design time itself.
Analysis of native channel opportunities is worth the time. Sometimes it's better to spend an extra six months agreeing on a cloud-native integration with your security team than to migrate a ten-year-old, undocumented legacy integration with a third-party delivery system.
Budget for the conversation, not just the code. On-prem migrations touch every team: IT, marketing operations, channel owners, security. The projects that ran smoothest were the ones where we had early access to all stakeholders, not just the technical lead. On those projects, we spent roughly 20% of project time just talking to each team, surfacing the pain points that had to make it into scope.
Treat Direct Marketing Agent versioning as an ongoing constraint, not a one-time install step. Because the agent install looks like a small task, it's easy to schedule late in the project plan and forget once it's done. But the agent version is tied to your SAS 9.4 maintenance level, and every agent connected to a given access point has to stay on the same version — so any future SAS upgrade means a fresh agent install, not an in-place update. Confirm agent compatibility in week one, and revisit it every time SAS 9.4 gets patched. (Small but useful note: the 15 July 2026 cutoff for SAS 9.4 M7 and older agents is a good forcing function to check this now if you haven't already.)
The bank's deployment eventually went live: fully operational, all five integrations running, campaigns reaching customers across SMS, call centre, and branch. CI360 is a modern platform, and it handles on-prem data well. But it needs to be set up for it: the data layer, the Information Map, the integrations, the Post Processes. None of that is automatic, and none of it is trivial. Get it right, though, and the result is a platform genuinely more capable than what it replaced.
If your organization is planning a move from SAS Marketing Automation to CI360, or is mid-migration and hitting walls, we'd be glad to compare notes. Reach out to the T1A team.
