Migrate from VWO to GrowthBook: what the move involves
The move from VWO to GrowthBook is mostly a rebuild of experiments, flags and metrics, not a copy of data, and the effort depends on how many visual tests and warehouse metrics your team runs today. Teams that use VWO for snippet-based campaigns, server-side flags and conversion goals will recreate each one in GrowthBook, either in its visual editor or as coded experiments. Because the research behind this page found no documented export path for VWO campaign logic, the inventory has to be done by hand: list every live and paused campaign, every server-side flag, the audience and targeting rules behind each, and the goal that decides whether a test succeeded.
Ownership usually splits across four roles. Product owners decide which tests carry over and which are retired. Engineers replace the VWO SDK calls in server-side code and swap the snippet on web pages. Analytics owns the metric definitions, which in GrowthBook are written as SQL against your own warehouse, so the warehouse data model and any existing conversion event names need review before anything is rebuilt. A platform owner sets up the self-hosted GrowthBook deployment, its database and access controls, and decides who can publish experiments. Confirm early whether your VWO plan includes the features you depend on, because that determines which parts of the old setup you actually need to reproduce.
Plan the cutover so no live test loses its assignment halfway through. The usual approach is to run the new GrowthBook experiment alongside the VWO campaign on a small share of traffic, check that both report comparable exposure counts, and only then pause the VWO campaign. Keep VWO data exports for historical results before the subscription ends, and record which tests were concluded so their results remain traceable. A practical first step is to ask your VWO account team, in writing, what campaign and goal data can be exported and in what format, and to treat any answer you do not get as an open risk in the plan.
Which VWO capabilities map to GrowthBook, and where the gaps are
This table compares the main VWO capabilities against self-hosted GrowthBook and marks each as clean, needs rework or gap. Read the status column first, then check the notes for what you must rebuild, confirm or replace with another tool. The main takeaway is that GrowthBook covers flags and experiments well, but VWO's heatmaps and recordings sit outside its scope and need a separate decision.
| Capability | VWO | GrowthBook (self-hosted) | Status |
|---|---|---|---|
| Feature flags and server-side experiments | Feature flags and server-side testing within VWO's feature experimentation product | Flags and experiments via GrowthBook SDKs; application code must switch from VWO SDKs to GrowthBook SDKs | Needs rework |
| Visual test editing | No-code visual editor for web variations | Visual editor exists, but existing VWO variations must be rebuilt as GrowthBook visual or coded experiments | Needs rework |
| Statistics and results | Built-in reporting for campaign results | Statistical analysis runs against your data source; confirm the methods and reports you need match GrowthBook's output | Needs rework |
| Warehouse analysis | Results primarily computed inside VWO | Runs read-only SELECT queries on your warehouse and transmits only aggregated statistics, so event data stays in your environment | Clean |
| Targeting and segments | Audience targeting and segment rules in VWO | Targeting rules, sticky bucketing and holdouts; sticky bucketing and holdouts require self-hosted Enterprise, not the free Open Source plan | Needs rework |
| Approvals, SSO and team controls | Role and access controls in VWO plans | Free self-hosted Open Source allows 1 project; SSO and SCIM, advanced permissioning and approval workflows require self-hosted Enterprise | Gap |
| Personalization, heatmaps and recordings | Bundled behavior analytics, including heatmaps and session recordings | Not replaced by GrowthBook; plan a separate tool such as PostHog or OpenReplay, covered on sibling pages | Gap |
What data moves, what gets rebuilt and which integrations change
Most of a VWO to GrowthBook move is rebuilding, not transferring. Campaign definitions, goals and user assignment history need separate decisions, while event data stays where it already lives. The cards below separate what you can export, what you must recreate by hand and which application code changes.
Campaign and goal definitions
GrowthBook's documented importers cover LaunchDarkly and Statsig, not VWO, so your running VWO campaigns, variations, audiences and goals will be recreated by hand in GrowthBook. Export each campaign's URL targeting, variation logic, primary and secondary goals and traffic split from VWO into a spreadsheet before you start. Treat that sheet as the rebuild specification and confirm with VWO which exports its reporting offers. Visual tests need the GrowthBook visual editor or a coded experiment, and the choice should be made per test.
Feature flags and feature rules
Whether VWO exports feature flags in a machine-readable form is a question to put to VWO directly, because the supplied facts do not confirm an export option. If VWO can export flag keys, default values and targeting, you can map them to GrowthBook feature definitions with a script. If it cannot, record each flag's default, rollout percentage and targeting rule from the VWO console. Flags that gate live traffic should be recreated and verified in GrowthBook before VWO is switched off for them.
User assignment history
Users already bucketed into a VWO variation will not keep that assignment in GrowthBook unless you replicate the bucketing logic exactly, which is rarely practical. Plan for a clean break: either let running tests finish in VWO, or start new GrowthBook experiments with a fresh population and treat results across the two systems as separate datasets. Do not compare pre-migration VWO conversion counts with post-migration GrowthBook results as if they came from one test. Document the cutover date in each experiment record.
Event data in your warehouse
Event data does not need to move. GrowthBook analyzes experiments against your own warehouse, including Snowflake, BigQuery, Postgres, MySQL and others, running only SELECT queries and transmitting only aggregated statistics. Your team must define metrics as SQL against the tables that already hold conversions, page views and revenue, and confirm that the events you need are actually being sent to that warehouse. If your conversions only exist in VWO's reporting, you need a pipeline into the warehouse before GrowthBook can analyze them.
Application SDK and snippet changes
The VWO snippet and any VWO server-side SDK calls in your application must be replaced with a GrowthBook SDK, and the GrowthBook importer documentation says this switch is still required after an import. Each experiment call site needs a matching GrowthBook feature or experiment check, and the variant keys must match what your metrics and dashboards expect. Test both the client-side and server-side paths in staging, and keep the VWO code path behind a switch until every campaign has been closed.
The migration sequence from inventory to decommission
This sequence moves VWO tests and flags to GrowthBook one stage at a time, so each campaign is verified before traffic moves. Each step ends with a written output that the next step depends on.
Inventory every running campaign and flag
Export a list of every live VWO campaign, feature flag, goal, audience, traffic allocation and the pages or code each one touches. Record which tests are client-side visual changes, which are server-side or feature experiments, and which are personalization rules that have no GrowthBook equivalent. Product owners should confirm which tests must keep running and which can end. The output is a signed inventory with one row per item, a named owner and a decision (rebuild, end, or keep on VWO for now).
Pilot one test and one flag in GrowthBook
Deploy a self-hosted GrowthBook instance using the Docker image or the official Helm chart, then connect it to a non-production data source. Rebuild one low-risk visual test in the GrowthBook editor or as a coded experiment, and one simple feature flag using the SDK for your stack. Confirm that the platform's metadata database, file storage and authentication settings meet your hosting standards before any production traffic goes through it. The output is a working pilot that a reviewer has tested in a staging environment.
Define warehouse metrics and validate against VWO
Connect GrowthBook to the warehouse that already holds your conversion and revenue events, such as Snowflake, BigQuery or Postgres. Define each VWO goal as a metric using SELECT queries over that data, and check that exposure and conversion counts match what VWO reported for the same pilot period. Investigate any gap in assignment logic, attribution windows or bot filtering before moving on. The output is a metric set and a short reconciliation note explaining every remaining difference.
Run both platforms in parallel behind a flag
Wrap the VWO snippet or SDK call and the GrowthBook SDK call behind a single control flag so that engineering can switch between them per page or segment. Keep both platforms reporting for the same users during a defined window agreed with the analytics owner. Compare assignment rates, metric results and error logs each day. The output is a parallel-run report showing whether the two systems assign users consistently and agree on the metrics you rely on.
Cut over and close VWO campaigns
Stop launching new VWO campaigns first, then let tests that are already running finish so that their results remain valid. Move remaining flags and tests to GrowthBook once the parallel run is accepted, and remove the VWO snippet from templates after no campaign still depends on it. Export VWO reports, raw data and configuration for your records before you close the account, and confirm the retention terms in your contract. The output is a closed VWO account, an archived export and a removed snippet in every production template.
How the move changes by team size and starting point
If your VWO usage is mostly visual tests on web pages, the main decision is how each running test will be rebuilt. Teams can recreate simple page changes in the GrowthBook visual editor, which keeps the change close to the original, or move the test into code as a coded experiment, which gives more control over logic, timing and flicker. The editor route is usually quicker for copy and layout changes, while coded experiments suit tests that depend on application state or a single-page app. Plan for the snippet swap in either case.
- Editor-based tests: Rebuild each change in the visual editor and check that selectors still match the current markup.
- Coded experiments: Write the variant logic in your codebase and point it at a GrowthBook feature, which requires developer time for each test.
- Snippet replacement: Remove the VWO snippet from page templates and add the GrowthBook SDK, then test on staging with both tools removed from the critical path.
- Flicker and timing: Compare how each approach loads variants on slow connections before you switch traffic.
- Running tests: Keep VWO active for each test until its results are recorded and the replacement is verified.
Confirm with your team which of your tests use the visual editor in VWO and which use custom code, since that split sets most of the effort.
If VWO serves feature flags to backend services or mobile apps, the work centers on the flag inventory and the SDK switch rather than on page markup. You can import LaunchDarkly and Statsig configurations with GrowthBook's importers, but VWO is not covered by those importers, so flags are usually recreated by hand or scripted against your own export. Use OpenFeature where you want application code to stay portable across flag vendors, since providers handle the translation to the flag system.
- Flag inventory: List every flag, its default value, targeting rules and the services that evaluate it, then mark which ones are live tests.
- Feature recreation: Rebuild each flag as a GrowthBook feature with the same fallback value and rules, and verify the values match in staging.
- SDK switch: Replace the VWO SDK calls with the GrowthBook SDK for each language, or with an OpenFeature provider if you want a vendor-neutral API.
- Cutover order: Move low-risk flags first and keep the VWO value as the fallback until each flag has been checked.
- Stale flags: Retire flags that no longer gate anything so the new inventory stays small.
Confirm with the VWO account team what export formats your plan supports, because that determines how much of the inventory you can script.
If your product events already land in a supported warehouse, GrowthBook can analyze experiments against that data directly. It runs read-only SELECT queries and transmits only aggregated statistics, so raw user-level events stay in your environment. Supported sources include BigQuery, Snowflake, Redshift, Databricks, ClickHouse, Postgres, MySQL, SQL Server, Athena, Presto or Trino and Vertica. This setup removes the need to send event data to a separate analytics vendor, but it moves metric definition work to your data team.
- Source check: Confirm your warehouse is on the supported list and that the credentials can run SELECT queries only.
- Metric definitions: Write exposure and conversion queries in SQL, which needs a data engineer or analyst who knows the event schema.
- Data quality: Validate that assignment events carry the fields GrowthBook needs before trusting results.
- Cost driver: Warehouse query volume is paid to your warehouse provider, so frequent analysis on large tables raises that bill.
- Governance: Agree who can create metrics and who reviews them, since metric errors affect every test that uses them.
Confirm your warehouse version and access model with your data platform owner before you commit to this path.
If you do not have a warehouse, or your VWO results come from VWO's own reporting, the migration needs a decision about where experiment data will live before any tests are rebuilt. GrowthBook's warehouse-native analysis depends on a supported data source, so you either stand one up or use another measurement path. Without a source, you cannot rely on the same warehouse-based statistics for the new tests, and historical VWO results will need to be archived separately.
- Source decision: Choose between a supported warehouse you operate and another measurement approach that you can validate.
- Historical results: Export VWO reports for running and closed tests and store them with dates, variants and metric definitions.
- Event instrumentation: Add or confirm the events that record exposure and each success metric before launch.
- Scope control: Start with a small number of tests so the data work stays manageable.
- Ownership: Name who maintains the data pipeline after the project ends, since that role is ongoing.
Confirm which measurement path your analysts can support before you schedule the first rebuild, because it decides whether GrowthBook's statistics can be used from day one.
What drives the cost and duration of the move
This table lists the inputs that change the size of a VWO to GrowthBook move and marks whether each one mostly adds one-time work or recurring spend. Read each row against your own campaign inventory, and use the last column to see what to request in a written scope before work starts. The main takeaway is that the rebuild and validation of live tests are usually the largest one-time items, while hosting and warehouse queries are the recurring costs to plan for.
| Driver | Why it changes cost or effort | One-time or recurring | What to ask for in a quote |
|---|---|---|---|
| Live VWO campaigns and goals | Each running campaign and goal must be mapped, rebuilt or retired, and checked against its live traffic. More campaigns mean more validation cycles. | One-time | A campaign-by-campaign inventory and a disposition for each: rebuild, code, retire or keep running until results are final. |
| Visual versus coded tests | Visual tests built in VWO's editor must be recreated in GrowthBook's visual editor or rewritten as coded experiments, which need developer time and code review. | One-time | A split of visual and coded tests, and which team owns each rebuild and its QA sign-off. |
| Warehouse readiness and metric definitions | GrowthBook reads your own warehouse with SELECT queries, so event tables, identity keys and metric SQL must exist and be agreed before results can be trusted. | One-time, then recurring query load | Which warehouse you run, who defines each metric, and how metric definitions will be documented and reviewed. |
| Applications and SDKs | Each web property, mobile app or backend service needs its VWO snippet or SDK replaced and retested. OpenFeature can reduce vendor-specific code, but each integration still needs work. | One-time | A list of every application and SDK in scope, and whether OpenFeature or native GrowthBook SDKs will be used. |
| Targeting complexity | Audience rules, segments, sticky bucketing and prerequisites may not carry over one to one. The LaunchDarkly importer documentation warns that advanced setups may include cases it cannot handle, and VWO rules need the same review. | One-time | A written review of targeting rules, with a list of any rules that will be rebuilt by hand. |
| SSO and approval requirements on Enterprise self-hosting | SSO and SCIM, advanced permissioning and approval workflows are listed on GrowthBook's pricing page as self-hosted Enterprise features and are absent from the free self-hosted Open Source plan. Choosing them changes both license cost and configuration work. | Recurring license cost, plus one-time setup | Which GrowthBook plan the scope assumes, the identity provider to integrate, and who approves experiment launches. |
| Hosting and operations | The bundled Docker image needs MongoDB or a compatible database, and the docs suggest a managed service for production. Kubernetes users can deploy the official Helm chart. Backups, upgrades and monitoring add recurring effort. | Recurring | Target platform (Docker or Kubernetes), database choice, backup and restore targets, upgrade cadence and on-call responsibilities. |
| Ongoing support and upgrades | GrowthBook releases new versions, such as v5.1.0 released on September 22, 2026 according to its GitHub releases page, so upgrades and testing will repeat over the life of the platform. | Recurring | Whether support is a fixed-scope handover or a retainer, and what is covered for upgrades and incident response. |
What usually goes wrong and how to prevent it
Most failed moves from VWO to GrowthBook trace back to sequencing and definitions. The risks below share one root: the two platforms run side by side for a period, and any gap in traffic, visitor identifiers or metric logic shows up as a wrong result. Each card names the check to run before you move the next piece.
Closing VWO while tests still allocate users
Pausing or archiving a VWO campaign can change which variation a returning visitor sees, which reshuffles their experience in the middle of a test. Before you touch the snippet, export each running campaign's traffic split, audience and goal, and keep VWO live until GrowthBook serves the same variations to the same audience. Confirm with VWO in writing how it treats campaigns that stop mid-test, and close campaigns only after their results are recorded.
Inconsistent bucketing between platforms
Each platform assigns visitors to variations with its own hashing, so a visitor can land in a different bucket once you switch tools. That moves users between arms and contaminates results. Identify the visitor identifier VWO uses, choose the GrowthBook hash attribute and seed deliberately so they match, and run an A/A check on both platforms before you route real traffic to GrowthBook.
Metrics defined differently in the warehouse
VWO counts conversions in its own collector, while GrowthBook runs read-only SELECT queries against your warehouse. A metric with the same name can still differ in event definition, denominator or attribution window, and that changes measured lift. Write each metric as a documented SQL definition, agree on it with analysts, and rerun your last concluded VWO test in GrowthBook to confirm the numbers agree before you trust new results.
Assuming an importer exists for VWO
GrowthBook documents importers for LaunchDarkly and Statsig, and those guides are the ones to plan around. Ask GrowthBook in writing whether it offers a VWO import before you schedule work. If none exists, every running campaign is a manual rebuild, and the importers still require switching the application from the vendor SDK to a GrowthBook SDK, with advanced setups possibly needing manual work.
Open Source plan limits growth
The free self-hosted Open Source plan includes unlimited users and unlimited API requests but caps you at one project. Teams that split sites, brands or regions into separate projects hit that cap quickly. Map your VWO accounts to GrowthBook projects during inventory, and price the self-hosted Enterprise tier before cutover if you need approval workflows, holdouts or SSO. Confirm current limits on the pricing page at the time you plan.
Questions teams ask before moving from VWO to GrowthBook
How much effort does moving from VWO to GrowthBook take?
The effort depends mainly on how many campaigns and flags are running, how many of them are visual tests built in VWO's editor, and how much of your analysis already sits in a data warehouse. A team with a handful of server-side experiments and a clean warehouse event model has far less to rebuild than a team with dozens of visual tests tied to custom JavaScript and goals tracked only inside VWO. Start with an inventory of live campaigns, then size each one by how it is implemented. Ask any vendor or partner for a quote built from that inventory and the written scope, not from a generic estimate.
Can our own team migrate from VWO to GrowthBook without outside help?
Yes, many teams do part of the work in-house, and the tooling supports it. GrowthBook documents a LaunchDarkly importer and a Statsig migration guide, which show the general pattern, but its LaunchDarkly importer documentation warns that advanced setups may include scenarios it cannot handle. A VWO move is not an import: you rebuild tests, swap the snippet and SDKs, and define metrics on your warehouse. Decide early which parts your engineers and analysts own and which parts need specialist help, such as hardening, backups or metric design. DeployOpen plans, implements and documents this kind of work under a written, fixed scope when that is the right fit.
How long should the parallel run between VWO and GrowthBook last?
Keep both platforms live only as long as needed to confirm that each migrated test and flag behaves as it did before. The length is driven by traffic volume, the number of tests that must reach a stable result, how many tests run on the same pages, and how confident your analysts are in the warehouse metrics. Tests with low traffic need more time to reach a decision, while a simple flag can be verified quickly. Set exit criteria per experiment, such as matching assignment rates and matching metric values, rather than a calendar date. Confirm with your team whether any VWO contract terms affect how long you can keep campaigns active.
What happens to historical VWO results after we switch?
Historical results stay in VWO unless you export them, and GrowthBook does not automatically recalculate VWO data. Export the reports you need to keep, including experiment definitions, goals, dates and final decisions, before closing campaigns. For ongoing analysis, GrowthBook runs read-only SELECT queries against your own data source, such as BigQuery, Snowflake or Postgres, and transmits only aggregated statistics. That means the long-term record for comparisons is your warehouse plus your exported archive. Confirm the export formats and retention rules with VWO and with your compliance team before you start closing campaigns.
Does GrowthBook replace VWO heatmaps and session recordings?
No. GrowthBook covers experimentation and feature flags, so it does not replace VWO's behavior analytics. VWO Insights heatmaps and recordings need a separate tool. Self-hosted PostHog or OpenReplay can cover session replay and heatmaps, and Matomo offers a paid heatmap plugin. Plan the replacement for these features as its own workstream, with separate decisions on masking, retention and hosting effort. Check with your privacy team how recordings are handled before you turn them on in any new tool.
What do our engineers and analysts need to provide?
Engineers own the code changes and analysts own the metrics, and both are needed from the start. Engineers must replace the VWO snippet and SDK calls with GrowthBook SDKs, because an importer alone does not switch the application over. They also need to set up self-hosting, which GrowthBook supports with a single Docker image and an official Helm chart for Kubernetes, with metadata in MongoDB or a compatible database. Analysts must define metrics against your warehouse tables and confirm that the event data matches what VWO recorded. Both groups should agree on experiment naming, environments and sign-off before the first test moves.
How DeployOpen scopes and runs a VWO to GrowthBook migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For a VWO to GrowthBook move, that means a written scope that names the VWO campaigns and snippets in use, the server-side flags that need an SDK swap, the GrowthBook deployment (the single Docker image or the Helm chart for Kubernetes), the MongoDB or compatible database behind it, and the warehouse data sources that GrowthBook will query. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before any work starts. Ask the provider to show which VWO campaigns are in scope, who owns the decision to close each one, and how the team will confirm that every running test kept its traffic split during cutover.
Ongoing needs are handled separately. Upgrades, backups, continuous security testing and operational support can be placed under a retainer after the migration, which matters because self-hosted GrowthBook releases move on their own schedule (the project shipped v5.1.0 on September 22, 2026). DeployOpen also prepares systems, controls and evidence for compliance readiness, such as access logs, change records and data handling notes for experiment data. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, so confirm with your assessor which evidence they expect before the engagement begins.
DeployOpen does not publish a price list. A quote follows from the written scope, so the useful inputs are the number of live campaigns, the number of server-side experiments, the warehouse platforms involved, whether self-hosted Enterprise features such as SSO, approval workflows or holdouts are required, and whether a retainer is wanted. Ask for each cost to be split into one-time work (inventory, rebuilds, cutover, closing VWO campaigns) and recurring items (hosting, database, warehouse query load, upgrades and support), and ask which items the client pays directly to cloud or warehouse providers. DeployOpen does not hold any vendor partnership or reseller status with GrowthBook, so the quote should name the GrowthBook edition and license terms the client is buying.
