How to migrate from Matomo to Astrina

Teams usually start this move for 3 practical reasons: the reporting flow feels simpler, privacy requirements have changed, or the old setup has grown into a stack of custom rules that only one person remembers. If that sounds familiar, you are not alone. A Matomo account can become very specific over time, and that specificity is often the first thing people want to keep while shedding the rest.

The trick is to treat this as a tracking project, not a tool switch. If you are planning every site you look after to share the same measurement logic, the migration needs names, numbers, and a written order of operations. Otherwise, you will spend the first week after launch asking why one conversion landed in Matomo and never appeared in Astrina. That is a bad week.

One short sentence matters here: keep the old data safe. Another: do not guess. A migration from Matomo to Astrina works best when you know what is tracked now, what must be rebuilt, and which reports need a clean handoff on day 1.

1. Why migrate from Matomo to Astrina

Most teams do not move because they dislike analytics. They move because the workflow around Matomo has become heavier than the questions they are trying to answer. A marketing manager may want 4 daily numbers, not 40 screens. A developer may want fewer trackers to maintain. A compliance lead may want a different approach to consent, data access, or retention.

There is also the reporting angle. Some teams want less time inside nested menus and more time inside a single dashboard. If that is your case, Astrina can be the cleaner fit, especially if you prefer a setup where the same site, report, and event structure can be understood by more than one person. For agencies, every client site in one dashboard can save hours that would otherwise go into toggling between accounts.

Switching platforms is not only about features. It is also about the people who have to use them. If 2 people in a 12-person team understand Matomo deeply, the tool is probably doing more than the team needs. That mismatch gets expensive fast.

2. Check your current Matomo setup

Before you touch anything, write down the full Matomo inventory. Start with tracked domains: primary site, subdomains, staging, and any cross-domain paths that matter. Then list tags, goals, custom dimensions, events, user roles, and integrations. Yes, all of them. A forgotten staging domain can pollute live reporting for months.

Next, inspect your event naming. If one team uses “CTA Click” and another uses “Button Click,” that is already two tracking standards. Keep the exact strings. The same goes for goals that rely on URLs, time on page, or event actions. If a goal fires on the third step of a checkout, write down the exact step number.

Access matters too. Note who can edit tags, who can see raw reports, and who only receives summaries. A migration can fail socially long before it fails technically. If 1 analyst and 4 marketers depend on the same Matomo account, they all need to know what changes on launch day.

Integrations are easy to overlook. Check whether Matomo feeds into CRM software, ad platforms, consent tools, or internal dashboards. If a report is exported to another system every Monday, that handoff needs a replacement plan. No handoff, no trust.

3. Map Matomo reports and events to Astrina

This is the part where many migrations go thin. People copy the pageviews, then forget the business logic. A better approach is to map each Matomo report to the Astrina report that will replace it, line by line, before you install a single script. If a Matomo report shows traffic by landing page, decide which Astrina page view metric should be the source of truth. If a Matomo event records “Download PDF,” keep that label or an equally clear one.

Do the same for conversions. If Matomo counts a signup after a thank-you page, and Astrina will count the same action on a form submission event, note the difference in the mapping sheet. That one detail changes how you compare old and new numbers for the first 2 or 3 weeks. It also prevents people from panicking when reports do not match exactly on day 1.

Keep the mapping simple enough that someone else can read it. A clean sheet often has 4 columns: Matomo item, meaning, Astrina replacement, and notes. One row per metric. One row per event. One row per goal. If the team later asks how to migrate from Matomo to Astrina for a second site, that sheet becomes the template.

If you use Astrina for broader site work, it helps to keep related reference material nearby, such as astrina for SEO-oriented tracking decisions or reporting structure. Not every team needs that on day 1, but the naming discipline carries over well.

4. Export the data and tracking configuration you need

Export what you can before you switch. Historical reports matter because they explain the baseline you will compare against later. Save the last 12 months if possible, or at least the reporting periods the business reviews most often. A product team may need 90 days. A content team may need 24 months. The number depends on the review cycle, not on the tool.

Document the settings too. That means Matomo site IDs, goal definitions, event categories, custom dimensions, filters, and any segments used in regular reporting. If you have time-based reports, save the time zone. If you have URL exclusions, save the exact patterns. Small things become large things after migration.

Keep copies of screenshots for reports that matter to leadership. A chart with 6 months of trend lines is easier to defend than a verbal description of what used to happen. If someone later asks why March traffic dipped, you want the old evidence close at hand.

Some teams export raw data for internal archives. Others document only the reports that are actively used. Either path can work. What cannot work is leaving the old setup undocumented and expecting memory to fill the gaps six weeks later.

5. Set up Astrina and install tracking

Create the Astrina account first, then add the site. If your team manages more than one domain, use the same naming pattern across all properties. “Main site,” “blog,” and “checkout” may sound obvious, but obvious names prevent mistakes when 8 tabs are open and someone is copying settings late on a Friday.

Install tracking with the method Astrina recommends for your site. For some teams, that means adding a script in the header. For others, it means a tag manager or another preferred installation path. The method matters less than consistency: one site, one verified tracker, one known place to maintain it. If you already keep documentation in a central place, link the install notes there and keep the code snippet versioned.

After install, test the basic pageview flow on at least 3 pages: homepage, a content page, and a conversion page. That quick sample catches many of the common setup problems, from missing scripts to duplicated loads. If a page is excluded in Matomo, check whether the same exclusion needs to exist in Astrina before launch.

For teams comparing plans while they set up the account, astrina can help frame the conversation around limits and growth. That is useful when you need to decide whether to migrate 1 property now or 5 properties in the same phase.

6. Recreate goals, events, and custom tracking

Rebuild the measurement pieces one by one. Start with goals, because they define success. Then move to event tracking, because event names are usually the easiest way to compare Matomo and Astrina side by side. After that, set up funnels and custom dimensions. This order keeps the first reports readable.

If Matomo tracks a form submission, reproduce the same trigger in Astrina. If Matomo marks a purchase after a thank-you screen, decide whether Astrina should mark it on the final URL, the button click, or the server-side confirmation. The technical choice should match the business meaning. That is the only point that matters.

Custom dimensions deserve special care. A dimension like “plan type” or “logged-in status” can change how every report is read. If Matomo stored that field in one place and Astrina stores it in another, write the mapping down with examples. One example beats 10 vague notes. For instance, “plan type = annual” should mean exactly the same thing in both systems.

When you are rebuilding more advanced structures, keep the event list short. Five solid events are better than 15 half-used ones. This also makes later QA faster. You can always add more after the first clean week.

7. Test the migration before going live

Testing should happen on a checklist, not by instinct. Open the site in a clean browser, trigger 3 pageviews, fire 2 events, and complete 1 conversion path. Then compare the Astrina data to the behavior you expect from Matomo. If cross-domain tracking exists, test that too. One missing linker can break the whole journey.

Check filters and exclusions before launch. If internal traffic was excluded in Matomo, confirm the same rule in Astrina. If a staging domain should stay out of production reports, test that exact condition. A single missed filter can make the first report look bigger than it should.

Cross-device and cross-browser checks help as well. A form may submit fine on desktop and fail on mobile. A checkout event may fire in Chrome and stall in Safari. Those differences are annoying, but they show up immediately if you test 2 devices and 2 browsers before cutover.

If your team relies on alerting or digest-style summaries, decide whether they should be configured before launch or in the first week after. A separate guide on whether you should choose should you choose analytics alerts can help with that decision.

8. Cut over, monitor, and retire Matomo

Pick a cutover date and announce it. Not a vague window. A date. If the marketing team, product team, and development team all need to update links or dashboards, they should know the exact Monday or Thursday when Astrina becomes the active source.

On launch day, keep Matomo running for comparison. That overlap period is usually short, but it is useful. Compare pageviews, events, and conversions for 3 to 7 days, then look for the reasons any difference exists. Sometimes the discrepancy is normal: a new filter, a different event trigger, or a change in the way a conversion is counted. Sometimes it is a bug. Either way, the comparison tells you where to focus.

Watch the first reports closely. The first 24 hours often reveal the basics: pageview totals, top pages, event volume, and whether the conversion path is working as expected. If something looks wrong, fix the tracking before you tell stakeholders the data is final. That order saves embarrassment.

Only retire Matomo when the team has confidence in Astrina and a documented reason to stop paying attention to the old account. Some organizations keep Matomo read-only for historical reference. Others close it once 1 full reporting cycle has passed. Either choice is fine if the data is archived, the mapping sheet is stored, and the team knows where to look next time a report changes.

One last practical note: keep the old screenshots, the mapping sheet, and the launch date together. They are the evidence trail. If someone asks six months later why a conversion shifted in week 2, you will have the answer in 3 files, not in memory.