The question behind this migration is always the same: "will we lose our history?" And the honest answer, the one that should shape the whole project, is: mostly yes, in the sense you mean. What you can do is stop the loss from mattering. That is what a good migration actually achieves, and it is entirely doable if you sequence it right.
Accept the two hard truths first
Truth one: your GA4 history will not move into Matomo in any complete, faithful way. Matomo has offered importers over the years and their coverage changes; verify the current state before planning around it, but plan as if the answer is no. Even where imports exist, GA4's aggregated exports cannot reconstruct raw visitor-level history.
Truth two: even running side by side, Matomo and GA4 will not agree. Different session definitions, different bot filtering, different consent handling, different counting. Both are self-consistent; they are different instruments. Your year-over-year comparisons will carry a permanent seam at the cutover date, and pretending otherwise is how migrations end in recriminations.
Once both truths are accepted, the plan writes itself: archive what you have, learn the new instrument's readings, and cut over with definitions documented.
Step 1: archive GA4 while you still can
Before anything else, switch on the BigQuery export if it is not already running (it is free at standard volumes and only exports from activation day forward, so every week of delay is a week of unarchived history). For the past that BigQuery cannot reach, export the reports that matter operationally: monthly sessions, sources, conversion counts, revenue, top pages, as flat files in a boring shared folder. Ugly, finite, and sufficient: what the business actually asks about history is almost always answerable from those aggregates.
This step has an underrated bonus: the raw BigQuery data remains yours and queryable long after you stop opening GA4, which softens the "losing history" fear from an amputation into a filing decision.
Step 2: install Matomo and run both in parallel
Stand up Matomo (the cloud vs self-hosted decision deserves its own hour) and implement it properly: same dataLayer, same event definitions, consent wired correctly, verified against real traffic, not assumed. If your tagging goes through GTM and a clean dataLayer, this is mapping work, not archaeology, which is one more argument for that architecture.
Then run both tools for at least one full business cycle, a quarter for most, long enough to include a campaign peak and an ordinary trough. You are building a translation table: GA4 says X, Matomo says Y, for the same reality. Expect systematic offsets. Write them down; they are your continuity bridge.
Step 3: map definitions, not just numbers
The seam in your reporting is survivable if it is documented. For each metric the business repeats (sessions, conversion rate, revenue, channel splits), record: the GA4 definition, the Matomo definition, the observed offset during parallel running, and the go-forward source of truth. One page. When someone in a year asks why 2025 and 2027 "don't match," the answer is a lookup, not a meeting.
This is also the moment to fix what GA4's defaults taught everyone to tolerate: prune the junk events, apply your naming convention, and define the funnel deliberately. A migration is the one time nobody defends the status quo, because the status quo is leaving.
Step 4: cut over, loudly
Pick a clean boundary (month or quarter start), announce it, switch dashboards and reports to Matomo, and keep GA4 collecting but demoted for one more quarter as a safety net. Then actually turn GA4 off: banner scripts, GTM tags, the property itself per your retention decisions. A migration that leaves both tools running indefinitely has not migrated; it has doubled the surface for discrepancy arguments.
Afterward, the archive from step 1 answers history, the translation table from step 3 answers continuity, and Matomo answers the present.
The realistic effort estimate
For a typical mid-size store or SaaS: a few days of implementation and verification, a quarter of patient parallel running (mostly waiting, not working), and a few hours of definitions documentation. The failure mode is never the technology; it is skipping the parallel period out of impatience and spending the next year unable to say whether the business changed or the ruler did. If you want the implementation and verification compressed into a week with the seams documented properly, that is a well-shaped engagement for exactly the kind of work I do; the parallel-running patience, unfortunately, cannot be outsourced.