First, identify the existing integration

The theme, modules and tag manager may load the same service in different places. Check product pages, basket, checkout and forms for both signed-in visitors and guests.

Decide what must be preserved before disabling the old integration: conversion events, consent preferences or form validation. Work in a test environment and check the Magento version and theme architecture.

Add fonts to the theme source

For a theme based on Magento's UI library, Adobe recommends placing font files in web/fonts and declaring them in web/css/source/_typography.less in your own theme. Do not edit the default theme or generated styles-m.css files: changes must survive asset regeneration.

The following example illustrates a local font declaration. Replace the name and path with your project's licensed files. For a theme without the UI library, use that theme's CSS mechanism and build process.

.lib-font-face(
  @family-name: 'Project Sans',
  @font-path: '@{baseDir}fonts/project-sans-regular',
  @font-weight: 400,
  @font-style: normal,
  @font-display: swap
);

Migrate measurement, not just the script

A page view is not an order. Explicitly define relevant events: product view, add to basket, checkout start and confirmed order. Check currency, value and possible duplicates.

If you choose Matomo or another platform, check the integration available for your store's version and frontend. A module suited to a classic theme may need adjustments for a custom frontend. Configure the data sent and avoid including customer emails or other details in events without clear justification.

Protect the form endpoint

Adding a spam-protection widget to the template is not enough. The token must be sent to and checked by the backend before the protected action. The secret key stays on the server.

For Turnstile, also check the expected action and hostname. Treat expired, reused or invalid tokens as failed verification. A clear message should let the user retry without rewriting the form.

What we check before launch

We go through affected pages and flows on mobile and desktop. We check fonts and accented characters, browser errors and possible blocks caused by Content Security Policy.

For measurement, we compare expected events with those received. For forms, we test valid submissions as well as missing or invalid tokens. In checkout, we check that the change does not affect placing an order.

We publish only after validation in the test environment and document the rollback steps. The true cost of migration includes this verification and ongoing maintenance, not just installing an extension.

Sources and documentation

Revised edition of the article originally published on Verosea in 2025.

How does this apply to your project?

Let's discuss it ↗