How to Migrate Website Analytics from Matomo to Astrina

If you are planning how to migrate website analytics from Matomo to Astrina, start with a narrow goal: replace the reporting your team checks every day, not every historical detail Matomo ever stored. That framing matters because a small migration is easier to verify, easier to explain, and far less likely to stall halfway through.

This guide assumes a practical cutover. You may keep a few Matomo exports for reference, but you do not need to rebuild every custom dimension, every archived report, or every server-side oddity that only one person remembers. Good. Leave the rest alone.

1. Identify the Matomo features you can safely leave behind

Start by listing what people actually use in Matomo during a normal week. For many teams, that is pageviews, referrers, a handful of goals, and maybe a few event labels. If nobody opens a report in 90 days, it is usually a candidate to drop.

Do not treat every Matomo feature as sacred. A custom segment that was built for one campaign in March is not the same as a primary conversion report that sales checks every Monday. One is a memory; the other is a workflow.

Also look at setup complexity. If Matomo depends on server-side rules, unusual plugins, or tracking logic that only works because an old tag is still on the site, that is a strong sign you should not copy it forward. Astrina works best when the setup is simple enough that another person can explain it in two minutes.

One useful filter is this: if a Matomo feature does not affect a decision, a meeting, or a report someone exports regularly, it can probably stay in the old system. That is not neglect. That is triage.

2. Export the minimum Matomo data you still need for reference

Export only what you will actually consult during the transition. Recent report snapshots are usually enough for comparison, especially if they cover traffic, top pages, goals, and event names. Save them as files you can search later. A screenshot buried in chat is not a record.

Keep a short list of goal names, event labels, and any notes that explain odd tracking behavior. For example, if a button click in Matomo is labeled “Lead Form Submit” but only fires after a thank-you page loads, write that down exactly. You will need the wording, not the memory.

If your team has a tracking spreadsheet, export that too. Date, page, event name, goal name, and owner are enough. Five columns can save five meetings.

Do not export everything just because the export button exists. Large archives create a false sense of safety, then nobody opens them. Small exports are easier to audit, easier to compare, and easier to hand to someone else next month.

For teams that keep technical notes in a wiki, create one page with the essentials: what Matomo tracked, which reports mattered, and which data points are intentionally being left behind. That page becomes the bridge between systems.

3. Map Matomo concepts to Astrina at a practical level

Now translate the small set of Matomo items into Astrina terms. Pageviews stay pageviews. Goals become the conversion points you care about most. Events remain events, but only the ones that affect reporting or decisions need to be recreated first.

Think in terms of priority, not perfection. If Matomo has 18 event labels and Astrina only needs 4 to support the current team workflow, build those 4 first. The other 14 can wait until someone asks for them with a real use case attached.

This is also the moment to decide what gets dropped on purpose. Old campaign dimensions, obsolete test goals, and one-off filters can be left behind if they do not support current reporting. A migration is not a museum exhibit.

Some teams want to preserve every naming convention from Matomo because it feels safer. Usually that just carries old confusion into a new tool. If the Matomo label was vague, fix it now. “CTA click” is not as useful as “Pricing page demo request click.”

If you need a reference for interpreting traffic sources in the new system, see what astrina traffic source numbers mean. That can help when source names do not match the old Matomo labels exactly.

4. Rebuild only the critical tracking in Astrina

Set up Astrina for the core analytics first. That means the pages, events, and conversions your team checks weekly. You are not trying to copy Matomo line by line; you are trying to restore the measurements that keep decisions moving.

Install the Astrina tracking on your site in the simplest place that works for your stack. If your site uses a tag manager, keep the implementation small and documented. If you prefer direct placement, note where the code lives and who owns it. Two owners are better than none.

Build the pageview baseline before anything else. If Astrina does not see the right pages, every later report will be noisy. Then add the most important events, one by one, and test each one in the browser. A hidden typo in an event name is a classic migration trap.

Do not clone every Matomo trigger. Rebuild only the interactions that matter now: form submits, pricing clicks, signup starts, file downloads, or whatever your team truly uses. If a legacy event never influenced a report, it does not deserve a fresh setup.

If your installation needs a clean setup path, use the Astrina agent setup pages directly: *. That is the fastest way to get from “we are switching” to “we have data again.”

For teams coming from a more technical Matomo deployment, it helps to keep a written checklist beside the browser tab. Step 1: confirm the base pageview tag. Step 2: add the first conversion. Step 3: verify that the event name matches the reference sheet. Step 4: check that the source and landing page look sensible. Simple beats clever.

5. Validate that Astrina is capturing the right interactions

Validation should be short and specific. Open the site in a real browser, trigger the top 3 interactions you rebuilt, and confirm that Astrina records each one. If the signup button fires but the thank-you page does not, you have found a problem before it becomes a reporting error.

Check pageviews on at least 2 or 3 representative pages, not just the homepage. A blog post, a product page, and a contact page usually tell you enough. If those behave differently, fix the pattern before handing the setup to the team.

Then compare the new data against your Matomo export snapshots. You are not chasing identical totals down to the last visit; you are checking that the same kinds of interactions are visible and that nothing obviously disappeared. A 20-minute sanity check can prevent a week of doubt.

If you want a deeper view of traffic quality versus outcomes, read should you trust astrina traffic. It is useful when someone asks why visits look fine but leads do not.

Keep an eye out for bot traffic too. If a spike looks strange, the article how to tell if astrina is can help you separate ordinary spikes from suspicious ones. That matters because a migration is the worst time to confuse noise with success.

One practical trick: test on a page with a known conversion point, then test on a page with no conversion at all. If Astrina records both correctly, your setup is probably stable enough to trust. If it does not, stop and correct the tag before the team starts using the numbers.

6. Decide what to do with Matomo history after the switch

After the switch, you have three common options. Keep Matomo read-only, archive exports, or run a short fallback period while Astrina becomes the primary source. Each option has a cost, and each one should be chosen on purpose.

Read-only access is often enough for larger teams. It lets people look up old reports without editing anything or creating fresh tracking habits in the old tool. That reduces confusion. It also reduces the chance of someone quietly backfilling data in the wrong place.

Archiving exports works best when legal, finance, or leadership wants a record of historical trends. Store the exported files somewhere controlled, with a filename convention and a date. “final_matomo_export” is not a convention.

A short fallback period makes sense if the team is nervous about the switch or if the site has multiple owners who need time to adjust. Keep it short. The longer Matomo stays active as a comfort blanket, the longer people delay learning Astrina.

Do not keep both systems in daily use forever. That creates mismatched numbers, duplicate conversations, and “which dashboard is right?” messages that waste everyone’s time. Pick a primary source and say so clearly.

7. Hand off the new analytics workflow to your team

The handoff is where migrations succeed or fail. Update the internal docs with the new report links, the new event names, and the one person who owns fixes when tracking breaks. Put the date in the doc. People forget dates faster than they forget opinions.

Rewrite team habits in plain language. If weekly reporting used to begin in Matomo, point people to Astrina instead. If product managers checked one Matomo segment every Friday, show them the Astrina report that now answers the same question. Use the same meeting, if possible. New tools stick faster inside old routines.

Train the team on the handful of numbers they will actually see. A small walkthrough beats a long screen-share with no example. Show them where to find pageviews, how to inspect an event, and where to check the primary conversion point. That is enough for most roles.

If access control matters in your process, assign roles now instead of later. One person can own tracking setup, another can read reports, and a third can review changes before they go live. That division prevents accidental edits and keeps responsibility visible.

Be direct about the cutover. Tell people that Matomo is archived, Astrina is active, and questions about the old setup should go to the migration notes first. Clear ownership saves time. Quiet ambiguity costs more than any dashboard ever will.

If you are still in the setup stage, return to the agent installation page and confirm the implementation is the one your team documented: *. Then lock the notes, close the old tab, and use the new workflow for the next report cycle.