Migrate from Adobe Analytics to Matomo

A single large site concentrates most of the risk in one place. The question is less about how many properties to move and more about whether one Matomo instance can absorb the write load and whether the historical replay fits inside the window you have before Adobe retention runs out. Sizing starts from pageviews per month, and Matomo's requirements guidance separates a single server for up to 1 million pageviews a month from a split application and database layout for up to 10 million. Plan the replay as a separate workload from live tracking so that backfill does not slow the production site.

• Size from measured pageviews: Pull monthly pageview counts from Adobe reporting and compare them with the sizing bands in Matomo's requirements FAQ before choosing a topology.
• Separate the replay queue: Run bulk Tracking API imports against a staging site or a throttled path so live visitors are not competing with historical requests.
• Confirm database engine versions: Matomo 6.0.0 requires MySQL 8.0 or newer or MariaDB 10.6 or newer, so check your target engine before you build.
• Freeze a cutover date: Agree one date when the tag switch happens and keep both systems collecting for a short overlap so you can compare totals.

Confirm with your own traffic reports and load tests, not with the bands alone, which describe typical sizing rather than your site.

A multi-site estate changes the work from one migration into a repeatable pattern. Each property needs its own site ID, its own tag configuration and its own mapping of props and eVars, and the shared decisions, such as the custom dimension scheme and the naming of goals, need to be made once and applied everywhere. Without a shared template, each brand ends up with a different taxonomy and cross-site reports stop being comparable. Treat the first property as the pilot that produces the template for the rest.

• Standardize the dimension scheme: Agree one list of Matomo custom dimensions that maps Adobe props, eVars and events, and reuse it across sites.
• Sequence by business value: Migrate the property with the most reporting dependency first, then the lower-risk sites, so the pilot exposes gaps early.
• Plan one history export per property: Adobe data feeds are configured per report suite, so list every report suite and its retention position.
• Decide on shared or separate instances: Consider whether all sites share one Matomo installation or whether business units need isolation, since that choice affects access control and backups.

Ask your implementation partner or internal team to show a written mapping for each property before any tag change goes live.

Teams that already run a tag manager can swap the Adobe tag for a Matomo tag in one container without touching page templates. Most of the effort moves into the data layer and the trigger logic, because Adobe variables are often set inline by developers. The main discipline is keeping the data layer stable while you change the destination, so that marketing and product teams do not see gaps in the events they rely on. Test in a preview or staging environment before publishing.

• Rebuild variables as data layer keys: Map each prop and eVar to a named data layer value, so the Matomo tag reads from the same source Adobe did.
• Version the container: Publish the Matomo tags in a separate version and keep the Adobe version available for rollback.
• Run both tags during overlap: Fire Adobe and Matomo side by side for a defined window and compare event counts.
• Retire the Adobe tag last: Remove the Adobe tag only after the comparison is accepted and the history export is complete.

Check that your tag manager's consent mode settings match the consent decisions you intend to record for Matomo.

When tags are hand-coded into templates, the migration is a code change across every page that loads the Adobe library, and it carries release risk. The safer route is usually to introduce a small, central tracking module that replaces the Adobe calls in one place, then move the page templates to call that module. This also makes the Matomo tracking code reviewable and testable. Hand-coded sites often have undocumented variables, so an inventory of what each page sends is the first deliverable.

• Inventory the calls: Search templates and scripts for Adobe calls, including the props and eVars set on each page.
• Centralize the Matomo code: Put the Matomo snippet and event helper in one shared file that every template uses.
• Use a feature flag for the switch: Gate the new module behind a flag so you can turn it off without a redeploy.
• Keep the names stable: Preserve the event and dimension names during the change, so historical comparisons still make sense.

Review the inventory with the developers who own each template, since undocumented calls are the most common cause of missing data after cutover.

An EU-only audience brings the CNIL conditions into the design. The CNIL sheet lists conditions for analytics trackers to be exempt from consent, including limiting purposes to audience measurement and A/B testing, a single publisher scope, no cross-checking with other processing, truncating the last byte of the IP address and a tracker lifetime of at most 13 months. Matomo's ePrivacy guidance adds that features such as User ID, heatmaps or session recordings remove the exemption, so the migration should not carry those across without a consent review. Confirm the rules with your data protection officer and the authority in each country where you operate, since Matomo's FAQ names France, Italy, the Netherlands and Spain.

• Check the exemption criteria: Compare the tag configuration against the CNIL conditions before enabling the tracker without consent.
• Drop non-exempt features: Leave out User ID, heatmaps and session recordings if you rely on the exemption.
• Set the retention period: Configure the data retention to match the 13-month limit where the exemption applies.
• Document the decision: Record the legal basis and the configuration in your compliance file.

Confirm the exemption position with counsel, because the criteria depend on configuration and national authority guidance.

A global audience brings different questions. The EU consent exemption criteria matter for European visitors but do not decide the design for the rest of the audience, where consent requirements vary by country. A global estate therefore needs a consent layer that can respond to each visitor's region, and an agreed rule for what Matomo collects when consent is not given. The EU-US Data Privacy Framework adequacy decision is relevant to transfers if you ship data to services in the United States, but a self-hosted Matomo in your chosen region changes where analytics data is stored. Ask where each instance will run, since Matomo Cloud data is stored in Frankfurt, Germany, and a self-hosted server sits wherever you put it.

• Map consent by region: List the countries in scope and the consent rule that applies to each one before configuring tags.
• Choose the hosting region: Decide whether the Matomo server sits in one region or several, and document it.
• Review transfers: Check any third-party tags or plugins that send data outside your chosen region.
• Test by geography: Verify consent behavior from representative locations before the cutover.

Confirm the consent requirements for each market with local counsel rather than relying on a single global rule.