VWO and AB Tasty under Wingify: stay or replace

VWO alternative options when the vendor changes hands

If your VWO or AB Tasty renewal falls due while the combination under the Wingify brand is still settling, get the renewal terms in writing before you sign, and treat self-hosted GrowthBook as the main alternative if you decide to leave. The public material this page relies on does not document the combined platform's roadmap, contract terms or where customer data is stored, so those answers have to come from the vendor. Ask for them as named commitments: which products stay supported and for how long, what changes to pricing and packaging, whether data processing terms and hosting locations change, and what happens to your accounts, users and contract if ownership changes again. Keep the request factual so you have a record to compare against later.

Put a change-of-control clause, a notice period and a data export right on the list. Confirm whether VWO and AB Tasty products remain under separate contracts, which SDK versions and snippet endpoints are guaranteed, and whether experiment results and raw event data can be exported in a usable format. These answers shape your negotiating position if you stay and the amount of work you face if you go. GrowthBook's self-hosted Open Source plan allows one project with unlimited users, and its code is MIT licensed outside its enterprise directories, so a small program can start there. Single sign-on, SCIM, approval workflows and holdouts sit in the self-hosted Enterprise tier, so check them against your governance needs on the GrowthBook pricing page before you decide.

If you leave, plan the move as a parallel run. GrowthBook ships its front end, API and statistics engine as one Docker image, stores metadata in MongoDB or a compatible database, and offers an official Helm chart for Kubernetes, as described in the self-hosting documentation. Your costs will come from hosting, a managed or self-run database, warehouse query compute for analysis, and internal engineering time to rebuild tests as coded experiments and swap SDKs. Keep VWO live until GrowthBook produces results for the same metrics, then close campaigns. GrowthBook does not replace VWO's heatmaps or recordings, so decide whether those features are part of the renewal before you commit.

What a renewal under new ownership should lock down

A renewal signed during an ownership change is the point to set terms, because the roadmap, data handling and pricing can shift once the deal closes. The public materials we reviewed do not set these terms for VWO or AB Tasty customers, so each point below needs a written answer from the vendor. Treat those answers as contract terms.

Product and support continuity

Ask which products the renewal covers: VWO testing, personalization, Insights and any AB Tasty modules you license. Get the support tier, the named escalation path and the period during which your current product versions will keep receiving security fixes, all in writing. Ask for the roadmap for each licensed module, and confirm whether anything is scheduled to be retired or merged during the term. A verbal assurance from the sales team does not bind the combined company.

Where experiment data is stored

Experiment results, visitor identifiers, event streams and recordings often contain personal or behavioral data. Confirm the hosting regions, the sub-processors that handle this data and whether the combined company plans to move it to new infrastructure during the term. Ask for the current data processing agreement and a notice period before any change. If you prefer to keep analysis in a warehouse you control, compare the vendor's storage with warehouse data sources, where queries run against your own data.

Price and billing unit limits

Vendors that bill on visitors, monthly users, seats or events can change the billing unit at renewal, which changes the invoice even when traffic is flat. Ask for a cap on annual increases, written notice before any change to the billing unit, and a list of modules bundled into your plan. Ask whether plan limits on campaigns, domains or recording retention will change after the merger, and have the answer written into the order form.

Complete data export

An export is only useful if it is complete. Define in the contract what you can take out: raw event data, experiment definitions, goals, audience rules, results history, heatmap data and recordings, along with the format of each. Confirm whether export is included in the subscription or billed separately, and how long the vendor keeps your data after termination. Test an export on a low-risk campaign before you sign, so you know what the file actually contains.

Exit without breaking live tests

Running tests and personalizations sit inside production pages and applications. Write down the termination date, how long the snippet or SDK keeps serving the last assigned variant, and what visitors see if the vendor stops responding. Ask for a transition window that lets you finish or close active campaigns. This clause decides whether a move to self-hosted GrowthBook can run in parallel with the old tests or has to be a single cutover.

What is documented about the combined platform, and what is not

The first thing to separate is what you can check yourself from what the public research for this page does not document. You can verify the product lines you pay for. Open your order form or subscription, note which product names appear (VWO, AB Tasty or both), which legal entity is named as the vendor, and which modules are enabled in the admin console, such as testing, personalization and behavior analytics. Those documents show what you license today, whatever the corporate structure looks like on the vendor's website. Keep copies with your renewal file, because the entity and product names on an invoice are the easiest things to compare after a change of ownership.

Several things are not documented in the supplied research and should not be treated as settled. These include the timing and terms of any ownership change, whether prices or billing units will change, where customer data will be hosted and processed after the combination, and what the product roadmap will be for each line. Treat any statement you have heard from a sales contact or a third party as unconfirmed until the vendor puts it in writing. Ask for a written statement before you sign a renewal, and do not rely on a blog post or a press summary as the source for these points.

Ask the vendor for a written statement covering four areas. First, product continuity: which products, snippets and SDK versions remain supported, and for how long. Second, data processing location: the regions where your visitor and event data is stored and processed, and whether that changes. Third, sub-processors: the current list, how it is updated, and how you are notified. Fourth, plan limits: any change to campaign counts, domains, seats, environments or recording retention. If the answers are vague or arrive only after the renewal deadline, that is itself a input for your exit planning, and the migration steps in the sibling pages can be costed while you wait.

Staying on VWO, moving to GrowthBook, or moving to PostHog

This table compares three paths on where experiment data lives, what testing and analysis each path covers, and what you must run yourself. Read the GrowthBook and PostHog columns alongside the features VWO bundles, because GrowthBook does not replace personalization, heatmaps or recordings. Confirm current plan limits and support terms with each vendor before you choose.

Decision area	Stay on VWO	Move to self-hosted GrowthBook	Move to self-hosted PostHog
Control of experiment data	Events and results are processed on VWO's hosted platform, so confirm data location and retention in your contract.	GrowthBook runs read-only SELECT queries on your warehouse and sends back only aggregated statistics.	Event data, experiments and recordings are stored on your own servers under your control.
Visual editor and no-code testing	VWO's visual editor is a core part of its suite for marketing teams running web tests.	Coded experiments are the main path. Confirm which visual authoring options your plan includes before you assume parity.	Confirm whether the no-code test authoring your marketers use is covered before you migrate campaigns.
Server-side feature flags	Flags sit inside the VWO suite. Check which SDKs and environments your contract covers.	The free self-hosted Open Source plan allows 1 project with unlimited users. SSO, SCIM and approval workflows need self-hosted Enterprise.	Flags and experiments are part of the same deployment. Confirm limits for your version and environments.
Statistics and analysis	Results come from VWO's reporting. Confirm which statistical methods and export options you rely on.	The statistics engine ships in the self-hosted bundle, and metrics are defined against your own data.	Experiments are built on PostHog's event model. Confirm the statistical methods available before you move tests.
Warehouse analysis	Analysis depends on VWO's captured events unless you export data. Confirm export paths today.	Supports BigQuery, Snowflake, Redshift, Databricks, ClickHouse, Postgres and other sources listed in its docs.	Event data is collected into PostHog. Confirm warehouse connectors for your stack.
Personalization, heatmaps and recordings	Included in the VWO suite, subject to plan limits on recordings and features.	Not replaced. GrowthBook does not provide heatmaps, session recordings or a personalization suite.	Covers heatmaps and session replay in the same tool. Confirm masking and retention settings.
Hosting and operations	None on your side, since the vendor operates the platform.	One Docker image plus MongoDB or a compatible database, with an official Helm chart. You own upgrades and backups.	A self-hosted stack you run and size. Confirm the components and resources your chosen version needs.
Support and vendor relationship	Vendor support is governed by your contract. Confirm response terms at renewal.	Open Source relies on community channels. Confirm what your Enterprise or implementation contract includes.	Confirm current support terms for self-hosted PostHog with the vendor before you commit.
What you must rebuild or replace	Nothing, if you stay on the current contract.	Marketer-built tests, personalization, heatmaps and recordings need separate tools or a sibling option.	Visual test setup and any warehouse-native pipelines you use today need to be rebuilt.

Which path fits your situation at renewal

A short renewal is mostly a question of time. The team needs enough runway to rebuild tests and flags elsewhere without losing results or leaving live campaigns unmanaged. Ask the vendor to confirm in writing what happens to running campaigns, stored results and access once the term ends, and whether you can pause new campaign creation while live tests finish.

Term options: Ask for a month-to-month or short extension, and confirm the notice period and any fee for early exit.
Export rights: Confirm which experiment results, audience definitions and raw event data you can export, and in what format.
Campaign freeze: Agree how live tests will be closed, so visitors do not stay in a variant with no owner.
Parallel scope: Start with two or three low-risk experiments in self-hosted GrowthBook pricing plans, so the team learns the workflow before the full inventory moves.
Decision dates: Set the go or no-go date for the migration and name the person who owns metric definitions before the notice date.

Check whether the notice date falls before your team can finish the first parallel comparison, and if it does, negotiate the extension first.

How to plan a move from VWO to self-hosted GrowthBook

This sequence takes a team from an inventory of what VWO runs today to a self-hosted GrowthBook installation, rebuilt experiments and a closed VWO account without breaking live tests. Each phase ends with a check you can confirm before moving on.

Inventory campaigns, flags and metrics
Product, growth and engineering leads list every running and scheduled VWO campaign, every server-side feature flag, each goal or metric, and the audiences and segments tied to them. Record the traffic each test receives, the pages or code paths it touches, and who owns each item. The step is done when every live test has an owner, a success metric and a named replacement decision, so nothing is discovered only after the VWO contract ends.
Confirm the GrowthBook edition and hosting plan
Decide which GrowthBook self-hosted edition fits the features in use. The free self-hosted Open Source plan includes one project and unlimited users, while SSO, SCIM, approval workflows, holdouts and sticky bucketing sit in the self-hosted Enterprise plan. Confirm current terms with GrowthBook, then choose the deployment path, either the official Helm chart for Kubernetes or the single Docker image, along with a managed MongoDB or compatible database and file storage. The step closes with a written architecture note approved by security and platform owners.
Stand up GrowthBook and connect the warehouse
Platform engineers install GrowthBook in the organization's own environment, configure the metadata database, and set up authentication. Data engineers then connect the warehouse or database that holds the event data, such as Snowflake, BigQuery or Postgres, using a read-only account. GrowthBook runs SELECT queries and receives only aggregated statistics. The step is done when a test dashboard loads, the warehouse connection passes a health check, and an access review confirms that the service account cannot write to production tables.
Define metrics on the warehouse
Analytics engineers translate each VWO goal into a metric defined as SQL against the warehouse, covering conversion events, revenue, and guardrail metrics such as error rates or page speed. Agree the exposure event for each experiment so assignment and outcome data line up. Because the research supplied does not include a VWO importer, expect these definitions to be written by hand. The step is complete when each metric has a reviewed query, a documented owner and a test run that matches the figures VWO reported for a past campaign.
Rebuild tests as coded experiments or in the editor
Developers rebuild each running campaign either as a coded experiment using a GrowthBook SDK or as a visual change in GrowthBook's editor, depending on what the test changes. Simple copy or layout tests may suit the editor, while logic-heavy or server-side tests usually need code. Product owners review each rebuilt variant against the original VWO design. Confirm with GrowthBook how its visual editor handles the page types on your site before committing. The step closes when every rebuilt experiment passes a QA checklist on a staging environment.
Swap the VWO snippet and SDKs in staging
Engineers remove the VWO snippet and any VWO SDK calls from a staging build and add the GrowthBook SDK and the matching feature flag evaluation code. If the team uses OpenFeature in its application code, the change can be limited to the provider layer. Run both paths side by side for a defined check period to confirm that assignments are sticky and that exposure events reach the warehouse. The step is done when staging metrics match the expected assignment split and no visitor sees two variants.
Roll out, then close VWO campaigns safely
Release the GrowthBook build to production with flags that allow a fast rollback. Keep each VWO campaign running until its GrowthBook replacement reports reliable data, or end it with a deliberate final variant so visitors keep a consistent experience. Export VWO reports and raw data you need for historical records before the subscription ends, and check the export format with VWO first. Remove the VWO snippet only after the last campaign has closed. The step is complete when VWO no longer serves any page, the exported archive is stored under your retention policy, and the team signs off.

What costs move when you leave VWO

The VWO subscription runs until the contract ends, so the first cost question is the notice date, not the replacement price. Check your order form for the term, the renewal mechanism and the notice period, and confirm with VWO whether any usage overage or add-on, such as a recording or personalization module, is billed separately. Whatever you pay VWO during the overlap is recurring until the contract closes, and that overlap is usually the largest single line in a move. On the GrowthBook side, the self-hosted Open Source plan carries no license fee, and the GrowthBook pricing page lists it as free with unlimited users, 1 project and unlimited API requests. Your recurring costs there are infrastructure and people: hosting for the GrowthBook image, a MongoDB or compatible database (the self-hosting documentation suggests a managed service for production), storage for uploads, and warehouse compute for experiment queries, which GrowthBook runs as SELECT statements against your own data source. Ask your warehouse team to estimate query volume per experiment, because that cost scales with event volume and metric count rather than with seats. The cost that many teams miss is the Enterprise tier. Single sign-on, SCIM provisioning, advanced permissioning, approval workflows, holdouts and safe rollouts are not in the free self-hosted plan. If your VWO contract relies on those controls, price the self-hosted Enterprise license as a separate line and request the quote in writing. The GrowthBook Enterprise license is also the reason to read the LICENSE file carefully, since the enterprise directories are not MIT licensed.

The largest one-time costs are engineering effort and parallel running. Rebuilding visual tests as coded experiments or in GrowthBook's editor, swapping the VWO snippet and SDK calls, and defining metrics on your warehouse all consume developer, analyst and QA time. Estimate these per active campaign and per flag, and ask any implementation partner to state those effort assumptions in a fixed-scope quote with named deliverables. Parallel running is a recurring cost of its own: while VWO and GrowthBook both serve traffic, you pay for both tools and for duplicated instrumentation. The cost drivers that move the total most are the number of running campaigns, the number of environments and domains you carry, the volume of events sent to the warehouse, and how many people need SSO and approval controls. Ask for a quote that separates one-time work (inventory, migration, validation, documentation) from recurring items (hosting, database, warehouse compute, Enterprise license, support retainer, upgrades). Also ask how upgrades to the current GrowthBook release line are tested and who pays for them, and confirm that the quote excludes any VWO-side fees you still owe.

Evidence to collect for a vendor change review

A stay-or-replace decision for VWO or AB Tasty is easier to defend when the file holds written vendor statements, contract terms and your own records side by side. The cards below list the documents reviewers usually ask for and what each one shows. DeployOpen prepares evidence and controls for assessment, but independent auditors and certification bodies issue any audit reports or attestations.

Ownership and continuity statement

Ask VWO or AB Tasty for a written statement covering who owns the combined product, which entity holds your contract after the Wingify merger, and what happens to product lines, hosting regions and support teams. The statement should name the dates it applies to. Note any changes to plan names, feature sets or support tiers that could affect your renewal. Keep the vendor's wording on file, since later emails may not match it.

Data processing terms and sub-processor list

Collect the current data processing agreement and the sub-processor list, including any new sub-processors added after the merger. Check where visitor data, tag events and recordings are stored and processed, and whether that changes under the combined company. Confirm how you receive notice of new sub-processors and how long you have to object. Your privacy team will compare these against your records of processing.

Data export and deletion procedures

Request the vendor's documented steps for exporting experiment results, raw event data, audience lists and campaign configuration, along with the formats offered. Ask how deletion works for visitor data, what is removed from backups, and how long deletion takes to complete. Test one export before you rely on it, because a plan change or account migration can alter what is available. Record the answers so a later migration to GrowthBook has a defined starting point.

Change-of-control clause

Read the assignment and change-of-control terms in your master agreement and order forms. Look for rights to terminate or renegotiate if the vendor is acquired or merged, notice periods, and whether pricing or service levels can change at renewal. Procurement should confirm which legal entity signed and whether a novation is required. Raise questions with counsel before the renewal notice date, not after.

Your test inventory and data flow diagrams

Build a list of running and scheduled campaigns, feature flags, audiences, goals and the pages or apps where the VWO or AB Tasty snippet or SDK runs. Draw data flow diagrams showing what leaves your site or application, where it lands and who can access it. Mark which tests depend on vendor-specific features, such as the visual editor or recordings. This inventory is the baseline for both a stay decision and any migration to self-hosted GrowthBook.

Questions buyers ask before moving off VWO

How much does moving off VWO cost, and what drives it?

The cost has three parts: software, hosting and a one-time engagement. GrowthBook's self-hosted Open Source plan is free, with unlimited users, one project and unlimited API requests, according to its pricing page. Self-hosted Enterprise adds SSO and SCIM, advanced permissioning, approval workflows, sticky bucketing and holdouts, and is priced on request. Recurring costs sit in your own cloud account: compute, a MongoDB or compatible database, file storage and warehouse queries. The one-time work covers inventory, rebuilding tests, metrics and cutover. DeployOpen does not publish prices. A quote follows a written scope, so ask for it to list campaigns, flags, domains, warehouse sources and applications that use the VWO snippet or SDKs.

How long does a migration from VWO take?

The pace is set by the size and complexity of what you run, not by a fixed calendar. The main drivers are the number of running campaigns and flags, how many visual tests must be rebuilt as coded experiments, how many warehouse sources need read-only connections, and how many applications embed the VWO snippet or SDK. Metric definitions that live only in analyst spreadsheets also slow the work. Fixed-scope engagements agree deliverables and timelines in writing before work starts, so ask for milestones tied to the inventory results rather than a generic duration.

What must our team provide during a VWO to GrowthBook migration?

Your team supplies the decisions and access that only your organization holds. Name an engineering owner for each application that uses VWO. Provide an export or read access to campaign, goal and audience definitions. Provide read-only warehouse credentials, since GrowthBook runs only SELECT queries and transmits aggregated statistics. Confirm which metrics your business uses to judge a test, and who signs off on results. Provide a cloud account or data center where GrowthBook will run, along with the identity provider for single sign-on if you choose the Enterprise plan. Each of these items should appear in the written scope with a named owner.

Can our in-house team migrate from VWO without outside help?

A small team with a limited number of tests can often do it in-house, using GrowthBook's self-hosting documentation, which covers a Docker image and an official Helm chart for Kubernetes. The harder work is usually not the install. It is rebuilding experiments, agreeing metrics on your warehouse and proving that results match what the business expects. Note that the supplied migration guides cover LaunchDarkly and Statsig, not VWO, so confirm with GrowthBook what can be carried over. Outside help makes most sense when the inventory is large, when metric logic is disputed, or when your security review needs documented controls and evidence.

Does GrowthBook replace VWO heatmaps and session recordings?

No. GrowthBook covers experimentation and feature flags, but it does not provide heatmaps or session recordings, so those workloads need a separate tool. VWO bundles behavior analytics with its testing, and recordings are retained for a period set by plan. Before you decide, list which heatmap and recording features your teams use, how long they need recordings kept, and how data is masked. Options to evaluate include self-hosted PostHog, OpenReplay, and Matomo with a paid heatmap plugin. Confirm each tool's current feature set and masking controls with its vendor, since these products change over time.

What happens to running tests during cutover?

Keep live VWO campaigns running until the replacement is verified, then close them one at a time. First, inventory each running campaign and its traffic, then rebuild it in GrowthBook and check that assignment and tracking match. Changing how users are assigned to variants can disturb results already in progress, so decide how existing visitors will be handled. Sticky bucketing, which is listed for self-hosted Enterprise, helps keep users in the same variant across changes. Close each VWO campaign only after its replacement shows correct data, and record the decision in the migration log.

Is the GrowthBook license acceptable for our compliance review?

GrowthBook's LICENSE file states that code outside its enterprise directories is MIT Expat licensed, while the enterprise directories fall under the GrowthBook Enterprise License. Ask your legal team to read the LICENSE file and identify which directories your chosen plan uses. Confirm the terms that apply to the version you deploy, because licenses can change between releases. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.

How DeployOpen deploys GrowthBook under a vendor change

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms in your own infrastructure. For VWO and AB Tasty under Wingify, we start by helping you decide whether to stay or move, then deliver a self-hosted GrowthBook plan only if you choose to leave.

How we scope

We agree a written scope covering your current VWO or AB Tasty contracts, products in use and integrations before any work starts.
The scope lists which campaigns, flags, metrics and data sources are in or out of the migration.
Engagements are fixed-scope, with deliverables and timelines confirmed in writing before work begins.

How we build

We deploy GrowthBook in your cloud account, data center or air-gapped network, with the database and storage you specify.
We connect GrowthBook to your own warehouse so experiment queries run as read-only SELECT statements on your data.
We test flag evaluation, targeting and statistics against known results before any live traffic moves.

How we hand over

You receive documentation of the deployed architecture, configuration, access model and backup procedures.
We document how each VWO campaign or flag was rebuilt, retired or kept, so your team can trace every decision.
We walk your engineers and analysts through operating GrowthBook, including how to swap SDKs and close old tests safely.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover GrowthBook version upgrades, such as tracking new releases, so your deployment stays current.
We prepare systems, controls and evidence for your compliance assessments, while independent auditors issue any reports.