VWO vs GrowthBook: which to choose

Which fits: VWO or self-hosted GrowthBook for your experimentation program

If your renewal is coming up, or a data residency rule means experiment data must stay in your environment, the deciding question is what your program actually runs on. VWO fits teams that depend on no-code web tests, personalization and bundled heatmaps or recordings, where marketers build and launch variations without engineering tickets. Self-hosted GrowthBook fits engineering-led teams that want server-side flags and warehouse-native statistics inside their own cloud account or data center, with the analysis running against their own data source using read-only SELECT queries and only aggregated results leaving the warehouse.

The trade-off is where the work moves. With GrowthBook, your team owns the Docker or Helm deployment, the MongoDB or compatible metadata store, backups, upgrades and the SDK integration in each application, and the visual editor is not the center of the product. Confirm the current feature list against the GrowthBook pricing page before you decide, because the self-hosted Open Source plan and the self-hosted Enterprise plan differ on items such as SSO, SCIM, approval workflows and holdouts, and the Open Source plan limits you to one project.

The decision turns on three questions. First, is behavior analytics in scope? If you need heatmaps and session recordings from VWO Insights, GrowthBook does not replace them and you will need a second tool. Second, must marketers edit tests without engineers? If yes, test whether GrowthBook's editor covers your use cases or whether you need coded experiments. Third, who will run the platform? Name the owner for uptime, data retention and upgrades before you sign anything, and ask any implementation partner to put that scope in writing.

Which option fits which scenario

This table matches common VWO situations with the option that usually fits better: GrowthBook, VWO itself, or a complement. Read each row by its condition, since the deciding factor is usually who runs tests, where data must stay, and whether heatmaps or recordings matter. Most teams will find that one condition dominates their choice.

Scenario	Better fit	Condition that drives the choice
Marketing-led visual tests on site pages	VWO, or GrowthBook only after a rebuild	GrowthBook's visual editor is less of a substitute for VWO's no-code workflow, so confirm editor coverage for your page types before committing.
Engineering-led server-side experiments	Self-hosted GrowthBook	Developers want flags and experiments in code, with SDKs in the application and results computed against the company's own data.
Warehouse-only data policy	Self-hosted GrowthBook	GrowthBook runs read-only SELECT queries against your warehouse and transmits only aggregated statistics, so raw events do not leave your environment.
Heatmap and session recording needs	VWO Insights, or PostHog or OpenReplay alongside GrowthBook	GrowthBook does not replace behavior analytics, so plan a separate tool for heatmaps and recordings and confirm its masking and retention settings.
Personalization for segments across the site	VWO, or a custom build on GrowthBook targeting	Personalization depends on audience and campaign tooling that GrowthBook does not document as a full equivalent, so confirm the exact targeting you need.
Small team without platform staff	GrowthBook Cloud or a managed partner, then self-host later	Self-hosting adds MongoDB, the bundled services and upgrades to someone's workload, so weigh staffing before choosing self-hosting.
Regulated data residency with in-house platform team	Self-hosted GrowthBook	The team can run the Docker image or Helm chart in its own cloud account and keep event data inside its own warehouse.
Need for approval workflows, SSO and advanced permissions	Self-hosted GrowthBook Enterprise	The free self-hosted Open Source plan lacks SSO, SCIM and approval workflows, so confirm the Enterprise license terms before planning.

How the core capabilities map across the two products

VWO's web testing workflow centers on a visual editor, where marketers and analysts change page elements, build variations and launch tests through a snippet on the site. GrowthBook's documented model is code-first: experiments are defined as feature variations and evaluated by a GrowthBook SDK inside the application, so developers usually build the variants. Treat this as the main gap for non-technical teams, and confirm the current state of any visual or no-code editing in GrowthBook's documentation before you commit.

Editor dependence: List the VWO editor functions your marketing team uses each week, such as element edits, custom code and audience targeting, and confirm how each one would be delivered without that editor.
Campaign rebuild: The documented importers cover LaunchDarkly and Statsig, not VWO campaigns, so plan to rebuild live VWO tests by hand.
Snippet replacement: Pages that load the VWO snippet need a GrowthBook SDK integration instead, and the change must be tested on each template.
Plan-dependent features: VWO's testing features vary by plan, so check the current VWO plan comparison for every feature you depend on.
Rendering behavior: Flicker and load impact on client-side variants depend on your implementation, so measure them on your own pages.

Before you decide, export your VWO campaign inventory and mark each test as code-buildable, editor-dependent or retired.

Capability comparison from supplied facts

This table sets VWO's web testing and feature experimentation against self-hosted GrowthBook on the dimensions that drive a replacement decision. Rows marked to confirm with VWO reflect facts we have not verified, so treat them as questions for your vendor rather than answers. The main takeaway is that GrowthBook's core experimentation and flag engine is open and self-hostable, while enterprise governance features and VWO's visual editor and behavior analytics need separate evaluation.

Capability	VWO	Self-hosted GrowthBook
Visual editor for web tests	Confirm with VWO which editor features and plan tiers apply to your account	Not a documented visual editor in the supplied facts; plan coded experiments or confirm current editor support
Server-side feature flags	Confirm with VWO whether feature experimentation is included in your plan	Built into the self-hosted platform with SDKs; the application must use a GrowthBook SDK after migration
Statistics engine	Confirm the statistical methods and reporting options with VWO	Python statistics engine ships in the same Docker image as the front end and API
Data location	Confirm where VWO stores event and experiment data and which regions are available	Experiments query your own warehouse using only SELECT queries and return aggregated statistics
Hosting model	Vendor-hosted SaaS; confirm any on-premise or private hosting option	Self-hosted in your infrastructure via Docker or the official Helm chart for Kubernetes
License	Proprietary commercial license; confirm terms with VWO	MIT Expat outside the enterprise directories; enterprise directories fall under the GrowthBook Enterprise License
Free self-hosted tier limits	Not applicable; confirm whether any free tier exists	Open Source plan is free with unlimited users, 1 project and unlimited API requests
Features locked behind enterprise tiers	Confirm which plan tiers include personalization, heatmaps and recordings	Self-hosted Enterprise adds SSO and SCIM, advanced permissioning, approval workflows, holdouts and multi-armed bandits

Where the data lives and who controls the platform

Moving from VWO to self-hosted GrowthBook changes where experiment data sits, who runs the platform and how access is governed. The four cards below cover the decisions that matter most at renewal, from the warehouse query model to the evidence your compliance team will need.

Experiment data stays in your warehouse

GrowthBook analyzes experiments against your own data source, including BigQuery, Snowflake, Redshift, Postgres and several others, using only SELECT queries. It transmits aggregated statistics back to the platform rather than raw event rows. Your team still owns the warehouse access grants, query logs and retention policy. Check which tables and event fields the analysis queries touch, and confirm that your data governance team accepts read-only access from a self-hosted service. VWO's own collection path, by contrast, is defined by its snippet and its data processing terms, so compare the two data flows side by side.

Single image or Helm chart

GrowthBook ships its Next.js front end, Express API and Python statistics engine in one Docker image, and maintains an official Helm chart for Kubernetes. A small team can run it on a single host, while a platform team can deploy it into an existing cluster. Your operating effort depends on who patches the image, backs up the metadata store and manages the statistics workload. Ask your team to decide the target platform before you size the deployment, and confirm how upgrades will be tested against your own data sources.

MongoDB or a compatible metadata store

GrowthBook stores feature flags, experiment definitions and metadata in MongoDB or a compatible database. The documentation suggests a managed service such as MongoDB Atlas or AWS DocumentDB for production. Choosing a managed service moves backups and patching to a provider, but it also places metadata in that provider's region and under its terms. Self-managing the database keeps control in your hands but adds backup, failover and restore duties to your operations calendar. Confirm where flag definitions and user attributes will be stored before the design review.

SSO and SCIM need the Enterprise tier

The free self-hosted Open Source plan does not include SSO or SCIM. Self-hosted Enterprise adds both, along with advanced permissioning and approval workflows. For a regulated organization, this means identity integration is a licensing decision as well as a technical one. Map your joiner, mover and leaver process to SCIM provisioning, decide who may change production flags, and confirm that the Enterprise license terms cover your deployment model. The enterprise directories in the codebase fall under a separate license from the MIT-licensed core.

Compliance evidence, not certification

DeployOpen prepares systems, access controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. An independent auditor makes that determination. Ask VWO for its current data processing agreement, sub-processor list and security documentation, and confirm them during renewal, since terms can change after ownership changes. Then document how your self-hosted GrowthBook instance handles access, encryption, backups and logging so your auditor can test those controls directly.

What VWO bundles that GrowthBook does not replace

GrowthBook covers feature flags, experiment assignment and statistical analysis, but VWO also sells personalization, heatmaps and session recordings that sit outside that scope. Before you commit to a move, list every VWO product your team actively uses, not only the testing module. Personalization audiences that change page content for returning visitors, heatmap views of click and scroll behavior, and recordings that replay individual sessions each need a named replacement or an explicit decision to drop them. GrowthBook's experimentation and flag tooling does not replace any of these three, so a team that depends on them will still need a second tool after the migration.

If those needs are central, the choice is usually between keeping a separate behavior analytics tool or consolidating onto an analytics platform. Self-hosted PostHog combines experiments, heatmaps and session replay, and OpenReplay focuses on session replay, so both are natural candidates to evaluate, with the trade-offs covered on the sibling pages. Confirm in each product's documentation which heatmap types, masking controls and recording features your team needs, and test them on a staging site before you retire VWO Insights. Note that VWO's recording retention is a plan-level limit, so confirm with VWO which retention period applies to your plan and contract, and ask whether historical recordings can be exported before renewal. Those exports are often the only way to keep evidence for past design decisions.

Keeping VWO for behavior analytics while moving experiments to GrowthBook is a valid interim design, but it creates two sources of truth for traffic and conversion. Decide early which tool owns the visitor identifier, how page views are counted, and whether GrowthBook's warehouse-based analysis will compare against numbers that VWO reports. Ask your VWO account team to confirm whether the product you keep will keep running after any contract changes, and plan a review date at which the split design either stays on purpose or gets consolidated.

What each option costs to own, by component

Replacing VWO with self-hosted GrowthBook moves cost from one vendor invoice into several components, some paid once and some every year. Use these cards to separate the VWO subscription from the GrowthBook licensing, hosting, database and warehouse compute you would carry yourself.

VWO subscription and plan tiers

VWO bills by product and plan, and the limits on flags, environments, domains and recording retention differ between tiers. Your current cost depends on which products you run, how many visitors or events they touch, and whether you bought add-ons. Confirm current pricing and limits directly with VWO, and ask for the contract terms covering renewal, overage and notice periods, since these change how long you must keep paying during a move.

GrowthBook self-hosted licensing

The self-hosted Open Source plan has no license fee and includes unlimited users, but it allows one project. If you need SSO and SCIM, advanced permissioning, approval workflows, holdouts or safe rollouts, you need the self-hosted Enterprise tier, which is priced by a custom quote. Ask GrowthBook which features are in scope, how the Enterprise license is delivered and renewed, and whether the price scales with users or projects.

Hosting and the metadata database

GrowthBook ships its front end, API and statistics engine in one Docker image, with a Helm chart for Kubernetes. You pay for the compute, storage and network to run it, plus a MongoDB or compatible database. The docs suggest a managed service such as MongoDB Atlas or AWS DocumentDB for production, which adds a recurring service fee. Ask your platform team who operates backups, patching and high availability, and whether the database will be self-managed or bought as a service.

Warehouse query compute

GrowthBook runs read-only SELECT queries against your own warehouse, so each analysis consumes compute on Snowflake, BigQuery, Databricks or another supported source. This cost is usually already in your data platform bill, but experiment volume, refresh frequency and large event tables can raise it sharply. Agree with the data team on query schedules, partitioning and who owns the warehouse budget before the first experiment goes live.

One-time migration and rebuild effort

Moving off VWO is mostly a one-time cost: inventorying live campaigns and flags, rebuilding visual tests in GrowthBook or as coded experiments, swapping SDKs and defining metrics on your warehouse. The LaunchDarkly importer can carry over flags, but its documentation warns that advanced setups may not import cleanly and that the application still needs its SDK changed. Ask any implementation partner for a written scope listing the campaigns, flags and metrics included, and who validates results.

Ongoing staff time and upgrades

The recurring cost that is easiest to underestimate is internal staff time for upgrades, security patches, on-call coverage and experiment analysis support. GrowthBook releases new versions regularly, so someone must track them and test them against your database and warehouse connections. Decide which team owns the platform, how much of an engineer's time it consumes each month, and whether an external retainer will cover upgrades and testing.

What a move from VWO to GrowthBook involves

The sequence turns running VWO campaigns and any flags into GrowthBook experiments and feature flags that read metrics from your own warehouse, and it ends with VWO closed without disrupting live users.

Inventory running campaigns and flags
Your product or growth team lists every active and scheduled VWO test, personalization campaign, and any feature flags or server-side tests, with the pages or code paths each one touches, its traffic split, its goal, and its owner. Ask VWO which export options exist for campaigns, goals, and audiences, because the supplied facts do not document a VWO importer for GrowthBook, so expect much of this list to be manual. The step is done when every item has a status (keep, rebuild, retire) and an owner.
Decide which tests become GrowthBook experiments
For each inventoried item, decide whether it becomes a GrowthBook visual experiment, a coded experiment in your codebase, or a feature flag with a rollout. Visual changes that depend on VWO's editor usually need rebuilding, while server-side logic is better served by a coded experiment. Personalization rules and behavior analytics such as heatmaps or recordings are not replaced by GrowthBook, so record which of those you will keep elsewhere. The output is a decision register with one line per item.
Install GrowthBook and connect the warehouse
Your platform team deploys self-hosted GrowthBook, typically from its Docker image or Helm chart, and backs its MongoDB or compatible metadata store. Your data team then creates a read-only connection to the warehouse that holds your event data, so GrowthBook runs SELECT queries and receives only aggregated statistics. The step is done when a test connection succeeds and a sample metric query returns results in a non-production environment.
Define metrics on the warehouse
Analytics and data engineers translate each VWO goal into a metric defined from warehouse tables, such as a conversion event or revenue value, and check that the event definitions match what VWO recorded. Discrepancies between VWO's numbers and warehouse numbers are expected at this stage, so document the definition used for each metric. The step is done when each metric in the register has a tested query and a named owner.
Swap the snippet and install SDKs
Developers replace the VWO snippet on the pages in scope with the GrowthBook SDK or the visual editor script, and add GrowthBook SDKs to server-side code paths that used VWO. Where your application also uses a flag provider, OpenFeature can keep application code separate from a single vendor. The step is done when a staging environment assigns users to variants in GrowthBook and no VWO code is loaded on the migrated pages.
Run both tools in parallel
Keep VWO live for the campaigns you have not yet moved while the migrated GrowthBook experiments run on a separate traffic allocation. QA checks compare assignment rates, page rendering, and error logs between the two systems, and analysts confirm that GrowthBook's results match warehouse queries they run independently. Watch for double-counted exposures or users seeing both variants. The step is done when assignment, rendering, and metric checks pass for every migrated experiment.
Close VWO campaigns without breaking users
Stop new VWO assignments only after the GrowthBook replacement is serving the same variant logic, then let running campaigns end or stop them with the current winner applied in code or in GrowthBook. Remove the VWO snippet from templates and tag managers, and confirm no page still loads it. Before cancelling your VWO subscription, ask VWO how long data remains available for export. The step is done when VWO is no longer loaded on any page and you hold archived results for each closed campaign.

Questions buyers ask before choosing GrowthBook over VWO

How much does switching from VWO to self-hosted GrowthBook cost?

The cost is the sum of several components, and the license fee is usually the smallest of them. GrowthBook's self-hosted Open Source plan is free with unlimited users, 1 project and unlimited API requests, according to its pricing page. The recurring costs are the infrastructure to run the GrowthBook image and its MongoDB-compatible database, the warehouse compute that runs experiment queries, staff time for operations, and any Enterprise plan features you need, such as SSO and SCIM, approval workflows or holdouts. One-time costs include the migration of running tests, metric definitions and SDK changes. Ask any quote to separate these components so you can see which ones scale with your traffic, user count and test volume.

How long does a VWO to GrowthBook migration take, and what does it depend on?

Duration depends mostly on how many campaigns, flags and metrics you run, and on how many of them are visual tests rather than coded experiments. Visual tests must be rebuilt in GrowthBook's editor or as code, which takes longer than swapping a flag. Other drivers include how many environments and domains are involved, whether your warehouse already holds the event data GrowthBook needs, how many metrics must be defined and validated, and how cleanly running campaigns can be closed without breaking live traffic. No supplied figure gives a standard timeline, so ask for a duration in the written scope based on an inventory of your actual campaigns.

What does our team need to provide before a migration starts?

Your team needs to supply the inventory and access that no outside party can reconstruct on its own. This typically includes a list of running and scheduled VWO campaigns with their goals, audiences and traffic allocation, the feature flags and their targeting rules, and the domains and pages where the VWO snippet is loaded. You will also need access to the data warehouse that holds your event data, with credentials that allow read-only SELECT queries, and named owners who can approve metric definitions. Finally, provide a plan for who will maintain GrowthBook after handover, since operations and upgrades become your responsibility.

Can our own engineers migrate from VWO to GrowthBook without outside help?

Yes, a capable internal team can migrate, particularly for a small number of coded experiments and flags. GrowthBook documents a LaunchDarkly importer that reads projects and flags through an access token, and it also documents a Statsig migration path, but neither is a VWO importer, so VWO work is largely manual. GrowthBook's importer documentation also warns that advanced setups may include scenarios it cannot handle, and that the application still has to switch from the vendor SDK to a GrowthBook SDK. Teams that have many visual tests, strict approval rules or regulated audit trails often find that the planning, validation and evidence work takes more time than the technical swap. Decide based on your inventory and your team's capacity.

Does GrowthBook replace VWO heatmaps and session recordings?

No, GrowthBook is an experimentation and feature flag platform, and it does not provide heatmaps or session recordings. VWO bundles behavior analytics, and if you use those features, you need a separate tool for them. Self-hosted PostHog or OpenReplay can cover session replay and heatmaps, and Matomo offers a paid heatmap plugin. Plan this as a second workstream with its own data masking, retention and hosting decisions, and confirm the exact features of any replacement in its own documentation before you rely on them.

Are the free self-hosted GrowthBook limits enough for our program?

The free plan fits teams that need one project and no per-user cap, but it has limits you should test against your program. The Open Source plan allows 1 project, while the Enterprise features such as SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts are available only in the self-hosted Enterprise plan. If your organization runs separate product lines or needs governance controls, the Enterprise plan may be required, so compare your requirements against the GrowthBook pricing page before deciding.

When is a DeployOpen fixed-scope engagement worth it?

A fixed-scope engagement is worth considering when the migration carries regulatory, security or deadline pressure that your team cannot absorb in parallel with product work. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from that written scope. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen also prepares systems and evidence for compliance assessments, but independent auditors issue any audit report or certification.

How DeployOpen helps evaluate, implement and migrate GrowthBook

DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For VWO vs GrowthBook, we start with a written scope that separates the experimentation work GrowthBook can take over from the behavior analytics and personalization you may still need elsewhere.

How we scope

Inventory running VWO campaigns, feature flags, goals and the pages or domains where the VWO snippet loads.
Map which tests need GrowthBook's visual editor, which need coded experiments, and which need a separate tool for heatmaps or recordings.
Confirm your data warehouse, metric definitions and the GrowthBook edition required before any work starts, in a fixed-scope written agreement.

How we build

Deploy self-hosted GrowthBook with its Docker image or official Helm chart, backed by a MongoDB-compatible database in your environment.
Configure read-only warehouse connections so experiment statistics are computed from your own data, with access limited to SELECT queries.
Replace the VWO snippet and SDK calls in your applications, then test variant assignment, tracking and statistics in a staging environment before launch.

How we hand over

Document the deployment architecture, data source configuration, metric definitions and the runbook for creating and closing experiments.
Provide a cutover checklist that closes VWO campaigns only after the GrowthBook replacements are verified against live traffic.
Walk your engineering, analytics and compliance teams through the evidence trail, so they can answer questions about where experiment data lives.

How we support

Keep the GrowthBook instance current with upgrades, backups and configuration changes, as set out in the agreed scope.
Offer ongoing support, upgrades and continuous security testing as a retainer after handover, priced from the written scope.
Prepare system descriptions and control evidence for compliance assessments, while independent auditors issue any formal opinion.

VWO vs GrowthBook