Moving from Plausible to Databuddy involves two separate jobs: preserving the reports you already have and verifying the tracking you will use after the switch. A CSV export completes the first job. It does not automatically recreate historical visitors, sessions, goals, or funnels in a different product.
This guide covers an archive-and-cutover workflow. It does not import Plausible history into Databuddy or promise matching visitor totals. If continuous historical reporting is a requirement, resolve that requirement before removing Plausible.
Decide what needs to survive the switch
Record the site domain, reporting timezone, date ranges, goal definitions, custom event names, property names, and reports your team uses to make decisions. Include any imported history separately from data collected directly by Plausible.
Create a migration worksheet before changing code:
| Item | Existing definition | New implementation | Verification |
|---|---|---|---|
| Pageview | The pages and navigation that should count | One Databuddy installation | One initial view and one client-route view |
| Signup | The application outcome behind the goal | A stable completion event | A successful synthetic signup |
| Campaign | Campaign parameters and attribution rules | Tested landing-page reporting | A synthetic tagged visit |
| History | Native and previously imported reports | An access-controlled archive | Open files and reconcile date coverage |
Use synthetic examples in shared worksheets. Customer identifiers, personal data, API tokens, and exported reports belong in restricted storage.
Export the appropriate Plausible reports
Plausible provides a dashboard export for the selected period and filters, plus a site-settings export for native historical statistics. The dashboard export has row limits; a successful download is not proof that it contains every row. The full native export excludes previously imported data. Plausible also documents a Stats API for programmatic aggregated reports and separate Enterprise raw-event exports. Check the current availability and scope before choosing an export method. See Plausible's official export instructions.
For each archive, save a manifest containing the export method, site, date range, timezone, filters, included history, and download date. Open the files before cancelling access. Verify that your required pages, goals, and reporting periods are present. A ZIP filename alone cannot establish completeness.
Keep the archive in a reporting or storage system your team can access independently of the old subscription. Do not upload it to an analytics event collector: aggregated report rows are not new user actions.
Install Databuddy once
Create the destination website and follow the getting-started guide. For a Next.js application, use the App Router integration. For WordPress, follow the WordPress setup.
Check the root layout, tag manager, theme, plugins, and any legacy snippet. Choose one installation path. Keeping an old snippet while adding another copy of the same destination tracker can create duplicate measurements.
Run verification on a staging site or a clearly identified synthetic environment first. If you use a brief production overlap, review both tools' collection settings and your site's privacy requirements before enabling them together. Parallel tracking is a measurement technique, not a consent exemption.
Rebuild goals around the outcome they represent
A Plausible goal and a Databuddy event do not become equivalent merely because they have the same label. Document whether the original goal represented a page visit, button click, submitted request, or confirmed application outcome.
For example, track a completed signup after the application confirms it, using the browser event helpers or the server SDK as appropriate. Do not count a failed submission as a completed signup. Use a stable event name and an allowlist of useful properties rather than copying form contents into analytics.
Recreate the reports you actually need. For a funnel, verify event order, identity, progression window, and duplicate handling. The runnable Next.js signup-to-paid example demonstrates synthetic completion events and delivery failure recovery; it does not import historical funnels.
Verify a known journey before comparing totals
Use a fresh browser context for each test and write down the expected events before running it:
- Open a tagged landing URL and check the initial pageview.
- Navigate within the application and check the destination pageview.
- Complete one synthetic signup and confirm the completion event.
- Repeat a callback or revisit the success page and inspect duplicates.
- Fail a submission and confirm that it does not create a successful outcome.
Check both network delivery and the destination report. A request sent from a browser is not proof that the hosted reporting system accepted and displayed it.
When comparing platforms, align timezones, ranges, event definitions, filters, and collection settings. Record differences in visitor or session definitions. Do not tune the new tracker solely to force equal totals: the same traffic can produce different legitimate counts under different definitions.
Cut over with a rollback point
Record a cutover timestamp and code revision. Remove the Plausible installation from the intended environment, deploy, and verify that the old collector no longer receives new requests from your test journey. Confirm that Databuddy still records the expected pageviews and completion events.
If the new journey fails, restore the known installation while investigating. Preserve your configuration worksheet and archive so rollback does not depend on memory. Keep old-account access until the export and replacement reports are verified, subject to your retention requirements.
For the broader product tradeoffs, see Plausible, Matomo, and Databuddy compared. If your existing implementation is Matomo, use the Matomo migration workflow.