The value of analytics data is contingent upon its accuracy, consistency and governance. A Matomo migration may provide greater control over hosting, data ownership and privacy configuration, but it is not a like-for-like platform substitution and it is not a replacement for robust measurement design, implementation governance or business-side validation. A migration changes how data is collected, named, processed, retained and reported. If these areas are not planned in combination, the resulting implementation may appear operational while still producing figures that are not reliably comparable with the previous platform.
This risk is most material where the migration covers multiple websites, mobile applications, ecommerce journeys, consent requirements or complex reporting dependencies. Under these conditions, the objective should not be to reproduce every legacy report without review. The objective should be to preserve measurement quality through a controlled technical and operational transition.
TagDataTrust is the only certified Matomo Implementation Partner in the UK and supports organisations across discovery, implementation, testing and governance to help complete a platform change without compromising measurement quality.
1. Start with discovery, not implementation
The first stage should be a structured discovery exercise covering the existing analytics and tagging ecosystem. It is necessary to establish not only what is implemented currently, but also which parts of the existing setup remain useful, which are no longer trusted and which should be redesigned for Matomo rather than copied across.
Document:
- All websites, apps, subdomains and environments in scope
- Existing analytics properties, containers and tracking libraries
- Pageview and screenview rules
- Events, goals, conversions and ecommerce interactions
- Custom dimensions, custom metrics and user identifiers
- Campaign parameters and attribution requirements
- Consent categories and regional differences
- Data exports, dashboards, APIs and warehouse feeds
- Redirects, URL changes and known changes to the customer journey
- Teams and systems that depend on the existing reports
This inventory should distinguish between what is currently documented and what is actually being collected. In many implementations, these are not equivalent. Tags may have been added directly in a tag management system, through hardcoded scripts or by third-party vendors. Some events may also be generated from application code rather than from a common data layer.
A crawl of the website and an analysis of network requests should therefore form part of discovery. This helps identify redundant tags, undocumented events, duplicate transactions and tracking that is firing on the wrong pages.
The objective is not to automatically reproduce every existing configuration. The objective is to establish which measurements remain required, which can be removed and which should be redesigned for Matomo.
It is equally important to define what the migration will not solve. Moving to Matomo will not, by itself, correct unclear KPI definitions, inconsistent event naming, broken ecommerce logic, missing consent controls or reports that were never aligned with business decision-making.
Recommended action: produce a documented discovery output that distinguishes required tracking, redundant tracking, technical debt and non-equivalent measurement behaviours across platforms.
2. When a Matomo migration is likely to be appropriate
A Matomo migration is often appropriate when greater control over data hosting, retention, privacy configuration, or implementation ownership is required than the current platform permits. It may also be appropriate where the existing implementation has become difficult to govern across multiple brands, markets or digital properties.
In practice, Matomo is likely to be appropriate when:
- Stronger control is required over where analytics data is stored
- Privacy and consent requirements are materially influencing implementation design
- Dependency on a current platform no longer aligns with reporting or governance requirements
- The organisation can support the implementation, testing and ongoing ownership required for a controlled migration
- Stakeholders accept that some definitions, reports and historical comparisons may change depending on the target design
A Matomo migration may be less appropriate where the expectation is that a new platform will automatically repair longstanding data quality issues without broader implementation review. It may also be less suitable where there is no organisational appetite for discovery, testing, documentation and acceptance criteria.
Recommended action: confirm the business case for migration in operational terms, not only in platform preference terms.
3. Define the historical data position
Historical data is one of the most important constraints to address before the project begins.
If migrating from Google Analytics, imported history is generally aggregated rather than raw visitor-level data. It may support trend reporting for metrics such as pageviews, sessions, sources and event counts, but it will not necessarily support the full set of Matomo features. The Matomo documentation on importing data from Google Analytics should be treated as the reference point here, because the practical limits depend on the source platform, the import method and the reports to be preserved.
Depending on the source platform and import method, historical data may not provide:
- Visitor Log detail
- Complete visitor-level segmentation
- Native ecommerce logs
- Reconstructed funnels
- Full custom report functionality
- Reliable weekly or monthly unique visitor calculations
- Complete transaction-level detail
Imported data should be treated as a historical reporting reference, not as an exact recreation of native Matomo data. Imported history may support continuity for some reporting use cases, but it is not a replacement for native Matomo collection going forward.
It is necessary to agree in advance how historical figures will be used. For example:
- Pre-migration data remains available in the legacy platform
- Selected aggregated history is imported into Matomo for directional reporting
- Matomo reporting begins from a defined cutover date
- Historic dashboards are rebuilt with an explicit data-source label
- A separate archive is retained for audit and long-term comparison
Matomo itself does not impose a universal limit on the volume of data it can store. However, retention depends on the hosting model, infrastructure and configuration. Matomo On-Premise gives you greater control over retention and storage, while Matomo Cloud plans have defined raw data retention and export policies.
This decision should be made before implementation, because it affects site structure, reporting design and migration sequence.
Recommended action: define whether historic reporting will remain in the legacy platform, be partially imported for directional use or be rebuilt from a clearly defined cutover point.
4. Build an event and measurement mapping
A platform migration should not rely on a direct translation of event names.
Create a mapping document that records the current implementation, the required Matomo equivalent and the validation method for each measurement. At a minimum, include:
The mapping should define naming conventions, required parameters, data types and ownership. It should also identify measurements that are not supported in the same way by both platforms.
Inconsistent legacy naming should not be retained solely to simplify the appearance of migration. A controlled naming structure makes Matomo reports easier to maintain and improves the quality of subsequent analysis.
This is also the stage at which non-equivalences between platforms should be made explicit. Some measurements can be carried across with limited change. Others may need to be redefined because session logic, attribution behaviour, ecommerce structures or available reporting dimensions differ materially. A robust migration plan should document these differences before launch rather than explain them retrospectively.
Recommended action: create a measurement mapping document with a validation rule and owner assigned to each in-scope event, goal and ecommerce interaction.
5. Treat ecommerce as a separate workstream
Ecommerce tracking requires more than validating that an order count appears in a report. The complete customer journey should be tested, and Matomo’s ecommerce guidance should be used alongside the implementation design because the exact data structure and validation requirements can vary depending on site architecture and checkout flow. The official Matomo ecommerce documentation provides a useful baseline, but it does not remove the need for property-specific testing.
The complete customer journey should be tested, including:
- Product views
- Product list impressions and clicks
- Add-to-cart actions
- Cart updates and removals
- Checkout steps
- Shipping and payment selections
- Purchase completion
- Refunds and cancellations, where supported
- Coupons, discounts, tax and shipping values
- Product identifiers, names, brands and categories
- Currency and revenue handling
The purchase event must be protected against duplicate firing. This is particularly important where a confirmation page can be refreshed, revisited or loaded through a browser history action.
Payment journeys should be tested with approved test credentials and across the relevant payment methods. A previous TagDataTrust ecommerce tracking project identified failed purchase attempts that were being recorded as successful transactions. This type of issue can materially distort revenue, conversion rate and marketing performance reporting.
The migration should also confirm whether ecommerce data is available in the required Matomo reports, exports and dashboards. An order count that is technically correct but unavailable to downstream systems remains an implementation problem.
It is also necessary to define what ecommerce migration work does not solve. A new analytics platform will not correct checkout UX problems, payment-provider failures, product feed errors or inconsistent back-office order statuses. It may assist with clearer measurement of those issues, depending on the implementation, but it is not a replacement for correcting the underlying journey.
Recommended action: treat ecommerce validation as a dedicated test workstream with transaction deduplication, payment-path testing and downstream reporting checks.
6. Run both platforms in parallel
Parallel running provides a defined period in which the legacy and new implementations can be compared before cutover.
The duration will depend on the size and complexity of the business. It should be long enough to cover:
- Normal and peak traffic
- Full ecommerce and lead-generation journeys
- Different consent states
- Multiple devices and browsers
- Key campaign activity
- Mobile application releases, if relevant
- Recurring or delayed conversion journeys
During this period, the legacy platform and Matomo should receive equivalent measurement inputs where possible. Similar totals should not be treated as proof of equivalence. The underlying tracking requests and the conditions under which they fire should be compared directly.
Parallel running can reduce cutover risk, but it does not guarantee comparability on its own. Depending on the platforms involved, differences in session handling, attribution rules, bot filtering, consent behaviour, time zone settings, and identity logic may still produce variance even when the tagging is technically correct.
Parallel running should have a documented end date. Without a defined cutover, teams may continue platform comparisons indefinitely, with neither implementation formally accepted.
Recommended action: define the comparison period, the reconciliation dimensions and the cutover decision criteria before parallel tracking begins.
7. Reconfirm consent and privacy controls
Consent must be designed into the Matomo implementation rather than added after tracking has been tested. The relevant Matomo privacy and consent guidance should be reviewed as part of solution design, particularly when consent-based, cookieless, or hybrid approaches are under consideration, as the appropriate configuration may vary by jurisdiction, legal advice, and operating model. The official Matomo privacy controls documentation provides a useful technical starting point.
Document:
- Which consent category permits Matomo tracking
- Whether any cookieless or exempt measurement is used
- How consent is passed from the CMP to the tag management system
- What happens when consent is withdrawn
- How consent states differ by country or region
- Which data is anonymised before collection or processing
- How user identifiers and custom dimensions are controlled
- How retention and deletion requirements are applied
The Matomo tracker should not send data before the relevant consent decision has been made, unless the organisation has a documented and legally reviewed basis for a different configuration.
Matomo can support privacy-conscious analytics configurations, but it is not a replacement for legal review, CMP governance or clear internal policy. A platform decision on its own does not determine whether an implementation is compliant.
Consent testing should cover acceptance, rejection, partial consent, withdrawal and return visits. It should also confirm that tags loaded outside the main tag management system respect the same decision.
Recommended action: document the consent signal flow end to end, including default state, update behaviour, withdrawal handling and regional variation.
TagDataTrust has delivered consent implementations across large, distributed digital estates. The Tealium Consent Manager implementation case study illustrates why consent logging, automated quality assurance and clear operational processes are necessary when requirements extend beyond a basic banner configuration.
8. Account for redirects and URL changes
Redirects can affect both measurement and attribution.
Before launch, document any changes to:
- Page URLs
- Hostnames and subdomains
- Login and checkout domains
- Campaign landing pages
- App deep links
- Cross-domain journeys
- Internal search URLs
- Query parameters
Redirects should preserve required campaign parameters and should not introduce unnecessary intermediate hops. Test whether the Matomo tracker records the final page correctly and whether the original campaign information remains available.
When a website migration occurs at the same time as the analytics migration, the two testing activities should be separated where possible. Otherwise, a change in traffic or conversion data may be attributed to the analytics platform when the actual cause is a URL, redirect or journey change.
Recommended action: test final URLs, preserved parameters and cross-domain continuity under real journey conditions before launch.
9. Reconcile data using agreed tolerances
Reconciliation should be based on defined metrics and tolerances, not on a general judgement that the numbers look close. The purpose is to determine whether differences are acceptable and explainable, not to force two platforms to produce identical outputs where their methodologies differ.
Compare the two platforms by:
- Day
- Website or app
- Device category
- Country or market
- Landing page
- Source and medium
- Event type
- Goal or conversion
- Transaction count
- Revenue and currency
- Consent state, where available
Differences are expected. Platforms can use different session definitions, attribution models, timezone settings, bot filters, identity rules and consent behaviour. These differences should be documented rather than obscured.
For each material discrepancy, record:
- The metric affected
- The size and direction of the difference
- The likely technical or methodological cause
- The business impact
- The corrective action or agreed explanation
This creates a defensible record for reporting teams and stakeholders. It also supports future investigations if a difference appears after the legacy platform has been decommissioned.
Recommended action: define acceptable tolerances by metric and segment, and maintain a discrepancy log throughout the comparison period.
A practical approach
For most organisations, a controlled Matomo migration is more effectively managed when divided into structured stages rather than approached as a single implementation task.
A structured approach typically includes the following stages:
- Discovery and scope definition
Confirm properties, journeys, dependencies, consent requirements, reporting needs and known weaknesses in the current setup. - Target-state design
Define the Matomo data model, naming conventions, ecommerce structure, consent behaviour, hosting considerations and historical data position. - Implementation and technical QA
Configure tracking, tag management, validation rules and reporting outputs, with documented checks against each in-scope measurement. - Parallel run and reconciliation
Compare legacy and Matomo outputs over an agreed period, using defined tolerances and discrepancy logging. - Business acceptance and cutover
Confirm that the data is not only technically collected, but also understood, usable and accepted by reporting stakeholders. - Post-launch governance
Maintain documentation, monitor discrepancies, manage changes through release processes and review privacy controls over time.
This approach can reduce risk, although adaptation may be required depending on the complexity of the digital estate, development dependencies, and the extent of concurrent changes introduced during migration.
11. Rebuild reporting around the new data model
Existing dashboards should not be copied without review. Each report should be assessed for:
- Metric definitions
- Dimensions and filters
- Date ranges and time zones
- Attribution logic
- Historical versus native Matomo data
- Ecommerce and conversion calculations
- Data refresh frequency
- Export and API requirements
- User access and governance
Reports should clearly identify the point at which the data source changes. If imported history and native Matomo data are displayed together, it is necessary to make clear that the underlying data structures are not identical.
It is also important to test the reports with the relevant report users. Technical validation confirms that a number is collected. Business acceptance confirms that the number is understood and useful.
Recommended action: review every inherited dashboard against the new data model rather than copying reports by default.
12. Establish acceptance criteria before cutover
Acceptance criteria should be agreed during discovery, not written after implementation.
A Matomo migration may be ready for cutover when:
- All in-scope properties have been inventoried
- Required events and goals have been mapped
- Ecommerce journeys have passed end-to-end testing
- Duplicate transactions have been ruled out
- Consent behaviour has passed regional and state-based tests
- Redirects and cross-domain journeys have been verified
- Parallel data has been reconciled within agreed tolerances
- Priority discrepancies have been resolved or documented
- Required reports and exports are available
- Documentation has been reviewed by technical and business owners
- A rollback or remediation process is available
- Stakeholders have formally accepted the new implementation
A migration is complete when the organisation can use Matomo’s data with a clear understanding of what changed, what remains comparable and how the implementation will be maintained.
Recommended action: require formal acceptance from technical and business owners before decommissioning the legacy platform.
Final considerations
A Matomo migration may improve control, transparency and long-term flexibility within an analytics setup. It does not remove the need for clear measurement design, disciplined testing or realistic expectations regarding historical comparability. A measured position is generally the most reliable: Matomo can be highly effective when implemented with a clear target state, documented limitations and agreed acceptance criteria, but it is not a replacement for broader analytics governance.
TagDataTrust is the only certified Matomo Implementation Partner in the UK. A Matomo migration may provide stronger control over data ownership, hosting and privacy configuration, but it is not a replacement for disciplined implementation governance, technical validation or clear acceptance criteria. If planning a Matomo migration, it is necessary to define scope, risks and acceptance criteria with precision before implementation begins.
If you’d like to hear more on this topic and set up a 1:1 call with us, please use the contact form. Contact a Consultant
