Migrating from Exclaimer to Atlas Ink: A Practical Guide

By David, 2026-08-04

We've already written the architecture comparison between Atlas Ink and Exclaimer - short version: Exclaimer is a signature marketing platform applied largely in the mail flow, Atlas Ink is managed signature provisioning pushed into the mailbox from your own tenant. This article is the other document you need: the actual migration plan, in order, with the rollback points marked.

One promise up front: done in this order, there is no broken-signature day. The two systems don't conflict while both are running, so the cutover is a sequence of verifications, not a leap.

Step 0: Confirm what the signature is for

Before touching anything, write down who owns the signature and what it has to do:

• Owner. Atlas Ink treats the signature as IT policy - brand, current titles, legal footer - rather than ad space. If marketing runs banner campaigns through signatures today, bring them into the plan early.
• Compliance language. If policy demands a disclaimer on system-generated mail as well, plan it as an Exchange transport-rule disclaimer that runs alongside the pushed signatures - the two layers never conflict.
• Reporting. Atlas Ink gives you per-user rollout status - applied, pending, or failed - so you can prove every mailbox is on brand.

This migration is built for what most IT-owned deployments look like: keeping every mailbox on a correct, current, on-brand signature - and you'd rather do that from your own Azure subscription, out of the mail path, at always $1 per active user, per month, metered instead of per-seat.

Step 1: Inventory what Exclaimer is actually doing

Export the current state before touching anything:

• Templates. List every signature template, its HTML, and its assets (logos, banners, social icons). Most orgs find far more templates than they thought - retired campaigns, test copies, a "DO NOT USE" folder being used.
• Rules. Document which senders get which template under what conditions. Flag any rule keyed on recipient or message content - recipient-conditional signatures are an in-transit capability that mailbox provisioning intentionally doesn't replicate. If one of these rules is load-bearing, back to Step 0.
• Attribute usage. List every directory field your templates reference. This becomes your Entra hygiene checklist in Step 2.
• The mail-flow topology. Note the Exchange connectors and transport rules Exclaimer's server-side mode installed. You'll remove them in Step 6 - last, never first.

Step 2: Fix the directory before the templates

Atlas Ink hydrates signatures from Microsoft Entra ID at push time - name, job title, department, phone, office. Whatever attribute gaps exist today, mailbox provisioning will faithfully publish them in everyone's signature.

So run the audit now: for every mailbox in scope, are jobTitle, department, telephoneNumber, and office location present and current? Fix the source data, and wire HR changes into the directory going forward. This step is unglamorous and takes longer than every other step combined - and it's also where most of the migration's value lives, whatever tool you land on.

Step 3: Rebuild templates in Atlas Ink

Deploy Atlas Ink into your own Azure subscription, then rebuild the templates that survived your inventory - usually a fraction of the exported pile:

• Recreate the layout, replacing every hard-coded personal detail with Entra tokens.
• Re-host image assets; this is the natural moment to shed the 2 MB rebrand-era logo.
• Map Exclaimer's rule outcomes onto Atlas Ink's scoped assignment: the all-staff rule becomes the tenant default, department rules become group assignments, VIP exceptions become user assignments. Precedence is user > group > tenant - most specific wins, deterministically.

Nothing you do here affects production mail. Exclaimer is still applying signatures; you're building in parallel.

Step 4: Pilot on a real group

Pick a pilot that includes the awkward cases - a shared mailbox, a recent joiner, someone with a hyphenated name that breaks layouts, at least one heavy mobile user. Assign the pilot template, push, and use the per-user rollout status (applied / pending / failed) to verify every mailbox rather than sampling.

Have pilots send real mail to external addresses and check rendering in Outlook desktop, Outlook on the web, and a phone. Expected wrinkle: if Exclaimer's server-side stamping is still active tenant-wide, pilot users' external mail may briefly carry both a pushed compose signature and a stamped one. Either scope the pilot users out of Exclaimer's rules for the pilot window, or treat doubled signatures as the known cosmetic artifact of the overlap period - it disappears at cutover.

Rollback at this point: unassign the Atlas template. Exclaimer never stopped; nothing changed.

Step 5: Roll out by scope

Expand group by group - the same verification each wave, the same rollback property throughout. Atlas Ink's daily reconcile starts enforcing as each wave lands: if a user edits or clears their pushed signature, it's re-applied within a day (and for anyone who should legitimately keep a personal signature, switch that user to unmanaged deliberately).

Meter note: Atlas Ink bills per active user - a user counts in a calendar month only once a managed signature is actually applied to their mailbox. Your cost ramps with the rollout, not from a contract date.

Step 6: Cut over the mail flow - now, and only now

When rollout status shows green across the tenant and external spot-checks look right:

1. Disable Exclaimer's transport rules / connectors per its documented removal process, so outbound mail stops routing through the stamping service.
2. Watch mail flow for a settling period - message trace on outbound mail, confirm signatures still present (they are; they're in the mailboxes now) and no double-signature stragglers.
3. Decommission the Exclaimer tenant per your data-retention process, and collect the offboarding confirmation your records-of-processing wants - the synced directory copy should be deleted, and it's reasonable to ask for that in writing.

Your compliance posture changes at this step, in the direction reviews like: no third-party service in the outbound mail path, no vendor-held copy of your directory, signature data at rest in your own subscription. (If that's the part of this migration your security team cares most about, the data-residency deep dive is written for them.)

Rollback even here: re-enable the Exclaimer rules. The overlap is cosmetic, not destructive - which is what makes this whole migration safe to run calmly.

The one-page version

Two systems, zero conflict, rollback at every stage - the whole trick is doing Step 6 last. When you're ready to see the other side up close, the Atlas Ink page has the full author → assign → push walkthrough, and the side-by-side comparison covers anything Step 0 left unanswered.

Exclaimer product behavior referenced here is drawn from Exclaimer's public documentation as of August 2026 and summarized in good faith. Verify current removal and offboarding procedures with Exclaimer directly as part of Step 6.