Ask buyers how long their A/B testing migration took and few give a complete start-to-finish timeline. The clearest reported durations cover different milestones: a few weeks to switch on experimentation in a new tool, and about a year and a half to retire one platform and finish a rollout across two sites. Others describe first go-lives rather than completed migrations, so activation can be quick in some cases, but these interviews do not show how long a full migration usually takes. Two things stand out. A vendor shutdown fixes the day the old product stops, not the day its replacement is ready: some teams were ready before it, others moved afterwards and some went without. And once the tool is live, preparing, running and analysing each experiment takes weeks to months of its own. The companion reads are why teams switch A/B testing tools and what experimentation-tool buyers wish they'd known, where the ratings live.
What an A/B testing migration spends its time on
A vendor ends the product
Twice in these interviews a vendor set the deadline by withdrawing a testing product. When Google Optimize ended, one team “started to use VWO in parallel with Optimize, and then Optimize got sunset, so we fully used VWO.” Another stopped exactly then: “So we were using Google Optimize until October of 2023, until recently.” Others were on a new tool months after, and some still had none a year or more on. More recently a vendor that sold personalization dropped its testing, and the B2B companies using it were handed to new tools, a story told below. Where Optimize users went is on experimentation after Optimize; the budget line it left is on what buyers actually pay for an A/B testing tool.
Named in this context: Google Optimize · VWO · AB Tasty
The website sets the date, both ways
A testing tool sits on a site, so a new site moves its date. One retailer will not install a new tool on a shop it is about to replace: “I don't think we will do a gigantic implementation of a new thing for the old shop.” A company rebuilding its site “customized our own components so that the e-commerce team could continue on with certain personalization experiments and A/B testing,” and “So that added to our scope of conversion to JSS one.” It runs the other way too. At one company, after a move of its website's hosting, “we have struggled to keep SiteSpect reliable,” and “It's basically not worked properly for about a year”; the buyer says the cause was never found. As with CMS migrations, the site sets the order, and that page tells the story of a testing tool that waited for a late site.
Named in this context: SiteSpect · Adobe Experience Manager · AB Tasty
The old contract and the overlap
The old tool's contract decides when the move has to be finished, and buyers size the overlap around it. One company signed a one-year renewal with its old tool only to finish leaving it, a story told below. Another, held by its contract, plans to keep a tool “for the next six to eight months”; a third, waiting on an expiry, says “If we can move earlier, we will move earlier.” Some plan an overlap as a rule: one brand will “usually make sure there's a month overlap between the old product and the new product.” In a move between two flag-based tools, the overlap meant doing the work twice: “Right now, any time we create feature flags, we're creating them both just because everything's not plugged in to Optimizely yet, everyone's fully trained on it, all those things.” As with BI tools, the contract sets the window.
Named in this context: Optimizely · LaunchDarkly · Firebase
Engineering decides how much testing happens
Once the install is done, the developer time each test needs sets the pace. A team that moved its testing onto a feature-flag tool after Google Optimize ended found that “You have to code everything in the back end.” Another moved the other way, off a flag tool, because experimentation there “was really difficult and hard to manage versus how much easier Optimizely is,” a story told below. At one travel company, development teams spent a long time getting a tool to work before an agency was brought in. Why that pressure drives switches is on why teams switch A/B testing tools; what it means per test is below.
Named in this context: LaunchDarkly · Optimizely · Adobe Target
Pilots, selection and sign-offs come first
Several moves start with a pilot, and the pilot sets the pace of everything after it. A subscription commerce company, about six months after shortlisting its new tool, says “I think the platform has been really great through the POC process, through our first experiment process.” A healthcare manufacturer was “literally just in the pilot phase with them,” and half a year on described the pilot as done, with no wider rollout yet. A pilot does not always end in a purchase: “We just did a pilot with them last year,” says one buyer whose company did not adopt the tool. Even a short install can wait on approvals. At a financial-services company the tool went live about a month after onboarding, but one piece of the set-up “took a lot longer than we initially thought and required a bunch of people from different teams to be looped in and signing off on whether this was okay to do.” The effect: “Long story short, that prevented some of the tests we wanted to get live.” What went wrong there is on what experimentation-tool buyers wish they'd known. As with loyalty programs, the clock starts before the build.
Named in this context: Statsig · Adobe Target · VWO
How long does it take to switch A/B testing tools?
These interviews do not establish a typical duration, and few buyers give a complete timeline. Two buyers report completed work of very different scope: a few weeks to switch a new tool's experimentation on, and about a year and a half to retire one platform and finish putting a tool on a second site. Three more can only be approximated by comparing interviews with the same person: a tool live about a month after onboarding was being finalized, a launch about six months after shortlisting, and a tool live within about five months of first talks with the vendor. Those measure a module switched on, a multi-site consolidation and three first go-lives, so they should not be combined into a typical range. Several buyers describe first activations as short — one calls a go-live in the autumn, with tests by the end of October, the quickest it had seen — but the multi-site consolidation shows a full migration can take far longer, and the other long clocks belong to what surrounds the tool: the contract, the website, pilots and sign-offs.
How long does it take to prepare and run an A/B test?
Buyers describe weeks or months of work around individual experiments, and this is where they put their numbers, but they measure different stages. A former experimentation director at one large retailer describes its in-house tool: “We started out with basically about six weeks for every test for the entire life cycle of those three phases” — a full life cycle of planning, running and analysis. A packaged-food company says “It takes us over a month to get an AB test running either on our sites or in our life cycle” — time to launch. A team on a module that needed developers describes a couple of months of development and requirements per test, a story told below, and another team is “not able to launch one to two CRO tests a week like we would ideally want” — a pace it wanted, not a duration. These are a full test, a launch lead time, preparation work and a throughput goal, and they rest on four companies, so they are not a comparable per-test figure. What they show is that a tool being switched on does not mean a team can run experiments quickly.
Does a vendor shutdown determine when the replacement is ready?
Not necessarily. Google Optimize's retirement fixed when the old product would stop working, and for several buyers it prompted the move, but their replacements were ready at different times: one ran its replacement in parallel before the end and switched fully afterwards, one stopped around the shutdown, one was on its new tool about seven months after, one describes a long gap without any tool, and some still had no replacement a year or more on. When a second vendor withdrew its testing, the three B2B companies using it reached different arrangements — moving to the tool it handed them to, a free trial they doubt they will keep, and a one-year contract with another vendor. The end of the old product and the readiness of its replacement can come at different times; these examples do not show how often migrations finish before or after a shutdown. Vendors end products in other categories too, so this is not a claim that testing is unusual.
Do A/B testing migrations stay on schedule?
These interviews give too few plan-versus-outcome comparisons to answer. Where a buyer made the comparison, the project ran long: one installation step “took a lot longer than we initially thought”; one tool sat unused because the new website it was bought for launched six or seven months after it was due; and one planned launch of a new tool had not happened almost two years on, by another executive's account. Before the build, others were pushed a year for budget. That cannot show how often A/B testing migrations finish early, on time or late.
Want a review of your own stack?
Get my review →The stories behind the timelines
The counter-current: the activations that came quickly
The quick ones here are real: a new tool's experimentation switched on in a few weeks, a tool live about a month after onboarding was being finalized, a go-live one buyer called the quickest it had seen, a tool chosen because it was quick to set up, and one that a buyer found easier to onboard than another platform it runs. They share a shape — one tool on one site, with someone already able to run it — and they say nothing about which vendor is faster: Adobe Target appears on both the quickest and the slowest sides here. A fast activation also says nothing about how long a full migration takes, or how long it takes to prepare and run each test.
What this means for your testing plan
In these interviews the length of an A/B testing migration is set by what surrounds the tool — a vendor's end date, the old contract, the website, pilots and sign-offs — and once it is live, the time to prepare and run each test matters as much as the activation. Our recommendations, not practices buyers describe: when a vendor announces a product retirement, separate the old tool's last day from the date its replacement must be working, and budget and start early enough to run the two side by side before the shutdown where that is possible; size the old contract's renewal to the migration rather than the other way round; if the website is changing, date the testing work from the site launch; time one real test end to end during the trial, not only the installation; and keep the old tool's test history before it is switched off. For why teams move or stay, see why teams switch A/B testing tools.
Common questions
How long does it take to switch A/B testing tools?
These interviews do not establish a typical duration, and few buyers give a complete timeline. The two who give a number describe different work: a new tool's experimentation switched on in a few weeks, and a consolidation onto one tool across two sites that took about a year and a half. Some first activations were quick, but a full migration can take far longer, and selection, pilots, the old contract and the website around the tool add time.
What sets the date of an A/B testing migration?
In these interviews, mostly things outside the project: a vendor ending its product, the old contract's end, and the website, both when a new site is late and when a site move stops the testing tool working. Engineering time, pilots and sign-offs add to it.
How long does it take to prepare and run an A/B test?
Buyers describe weeks to months of work around each test, but they measure different stages: about six weeks for a test's full life cycle, from planning to analysis, at one large retailer; over a month just to get a test running at another company; and a couple of months of development and requirements per test on a module that needed developers. Those are a full test, a launch lead time and preparation work, not a comparable per-test figure. Timing one real test end to end during the trial is our recommendation, not a practice buyers describe.
Should you run the old and new testing tools at the same time?
Some buyers did: one ran its replacement alongside Google Optimize until the shutdown, one keeps a month of overlap between old and new tools as a rule, one created every feature flag in both tools during its move, and one renewed its old tool for a year only to finish leaving it. Others left a gap with no tool at all.
Do A/B testing migrations stay on schedule?
Too few buyers compared a migration with its plan to say. Where they did, one installation step took longer than expected, one tool sat unused because the new website launched six or seven months after it was due, and one planned launch had not happened almost two years on; others were pushed a year for budget. That cannot show how often these migrations finish early, on time or late.
A tech stack review, powered by the buyers who've been there
What matters most to you, a shortlist for your stack, and the next steps to take — built from hundreds of verified buyer interviews.
Get my stack reviewFree · no password · your answers are anonymized before they inform research like this.