> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# What's New in StagingPro V2 for BigCommerce
> StagingPro just got a major upgrade — 5–10× faster migrations that fix common errors on their own, live progress, and full control over how data lands. Plus your whole Vortex IQ AI toolkit, included free.
StagingPro V2 is a ground-up rebuild of the BC Migration engine you use today. The classic app has served thousands of store-to-store migrations; V2 keeps everything you rely on and rebuilds the machinery underneath it — so migrations run faster, recover from problems on their own, keep you informed in real time, and give you far more control over how your data lands on the destination store.
This page explains what's new, what's better, and how V2 differs from the classic version — in plain language, no jargon required.
**Nothing to set up, nothing to reconnect.** Your stores, environments, settings and full migration history are already there. When your organisation is enabled for V2, Store Migration simply appears in your Vortex IQ workspace as **StagingPro v2** — your BigCommerce stores connect exactly as they always have. And your whole Vortex IQ AI toolkit comes with it, [free](#now-included-free-your-vortex-iq-ai-toolkit).
## At a glance
| | Classic StagingPro | StagingPro V2 |
| ----------------------------------------- | ------------------------------------------------------------ | --------------------------------------------------------------------------------- |
| **Migration speed** | One item at a time, with a fixed pause between every item | Many items in parallel, automatically tuned to what BigCommerce allows |
| **When something fails** | Item is logged as an error; you fix and re-run | **Auto-Heal** diagnoses the failure and repairs it automatically, mid-run |
| **If a migration is interrupted** | Starts over from the beginning | **Resumes from where it left off** — completed work is never redone |
| **Pause / Resume** | Not available | Pause any running migration and resume it later |
| **Cancel** | Available (takes effect at the next phase) | Available, takes effect immediately |
| **Progress updates** | Refresh the page to see a percentage | **Live status stream** — watch items complete second by second |
| **Existing data on the destination** | Creates duplicates, unless you wipe the destination first | **Your choice**: skip existing items, update them, or make an exact copy |
| **Rehearsing a migration** | Not available | **Dry-run mode** walks the whole migration without writing anything |
| **Checking the result** | Manual spot checks | **Verify mode** re-compares source and destination, read-only |
| **Time & size estimate before you start** | Not available | **Forecast** predicts duration and sizes the run before you commit |
| **Image files** | Destination pulls images from the source store's public URLs | **Direct file transfer (WebDAV)** — including Page Builder widget images |
| **Storefront scripts** | Not migrated | Migrated |
| **Customer segments** | Not migrated | Migrated |
| **Migration history** | Available while records are kept | **Permanent** — every run's outcome and issue log is preserved |
| **Public API** | Registered-store API | **New organisation-level API** with self-serve docs and an interactive playground |
## The headline features
Migrations run in parallel and tune themselves to what your store can take. Hours of fixed pauses become minutes.
Common failures are diagnosed and repaired mid-run, while the rest of the migration keeps moving. Always on.
Pause and resume anytime. If anything is interrupted, it picks up exactly where it left off — with no duplicates.
A live status stream shows every item completing, with a plain-English reason for anything skipped.
Skip, Update, or make an Exact Copy — per migration. No destructive pre-wipe, no duplicates.
Entity counts and a Forecast before you start; Dry-run to rehearse, Verify to double-check afterwards.
### 1. Much faster migrations
The classic engine migrates one item at a time and waits half a second between every single item — and when BigCommerce asks it to slow down, it stops for a full 30 seconds. On a large catalogue, those pauses add up to hours.
V2 works in parallel. It watches how quickly BigCommerce is responding and continuously adjusts how many items it sends at once — speeding up when the store can take it, easing off before hitting rate limits rather than after. Each migration also runs in its own dedicated worker, sized to your store: a 50,000-product catalogue automatically gets more resources than a 500-product one.
### 2. Auto-Heal: migrations that fix themselves
In the classic app, when an item fails — say a product BigCommerce rejects because of a duplicate field — it's written to an error log, and it's up to you to fix it and run again.
V2 ships with **Auto-Heal**, and it's always on. When items fail, the engine diagnoses the cause, applies a safe correction (for example, removing a duplicate value or trimming an over-long field), and retries — while the rest of the migration keeps moving. Fixes are tested on a small sample first and only rolled out to the remaining items once proven.
Better still, V2 **learns across migrations**. Every diagnosed failure and its successful fix goes into a shared knowledge base, so a problem solved once — for any customer — is recognised and repaired instantly the next time it appears.
### 3. Pause, resume, and never lose progress
V2 checkpoints continuously as it works. That changes three things:
* **Pause** a running migration whenever you like — before a traffic peak, for example — and resume it later. It carries on exactly where it stopped.
* **Interruptions don't cost you the run.** If anything stops a migration midway, resuming continues from the checkpoint. In the classic app, an interrupted migration had to be resubmitted and started over from zero.
* **Re-runs are safe.** Because V2 remembers exactly what it already migrated, resuming against a destination that already has data will not create duplicates.
Cancel is still there too — and in V2 it takes effect immediately rather than at the next phase boundary.
### 4. Real-time migration status
The classic app updates a percentage that you see when the page refreshes. V2 streams progress live: which phase is running, how many items are done, the current rate, and a running time estimate that sharpens as the migration proceeds. Failed and skipped items appear in an itemised issue log — each with a plain-English reason — while the run is still going, not just at the end.
### 5. You choose how existing data is treated
This is one of the biggest practical differences. When the destination store already has data, the classic app either created duplicates or required you to wipe the destination's products, categories and brands first — all or nothing.
V2 gives you three **conflict strategies** on every migration:
| Strategy | In the app | What it does |
| -------- | ----------------- | ------------------------------------------------------------------------------------------------------------ |
| Skip | *Add New Only* | Leaves anything that already exists on the destination untouched. The default. |
| Update | *Update Existing* | Updates existing items with the source's values — including their variants, images, and other details. |
| Replace | *Make Exact Copy* | Updates everything, then removes items that exist only on the destination, so it mirrors the source exactly. |
No destructive pre-wipe, no duplicates.
### 6. A true replica
Under *Update* and *Replace*, V2 doesn't stop at the product record. A matched product's variants, images, custom fields, pricing rules and other details are reconciled to **exactly match the source** — additions, changes, and (under Replace) removals. After content migrations, a **content fidelity check** compares what landed against what was sent, so "it copied" and "it's identical" are no longer the same guess.
**Make Exact Copy** deletes data that exists only on the destination. For safety, V2 **refuses to run it against a live production store** — even if asked.
### 7. Know before you go: counts, forecast, dry run, verify
* **Entity counts** show exactly how many products, categories, pages and so on will be involved — before you start.
* **Forecast** estimates how long the migration will take and how much capacity it needs, priced to your actual scope: your selected entities, your picks, your conflict strategy.
* **Dry-run mode** walks the entire migration without writing a single thing to the destination — a full rehearsal.
* **Verify mode** re-runs a finished migration read-only and reports differences between source and destination.
None of these existed in the classic app.
### 8. Better file handling: WebDAV image migration
The classic app migrated product images by giving BigCommerce the source store's public image URLs to fetch — which required the source store to be publicly reachable, and could not handle Page Builder widget images at all.
V2 can copy the actual files across using **WebDAV**: product and content images, and — new — the images inside Page Builder widgets, which never travel by URL. Content links are rewritten to point at the destination, so your pages don't quietly keep referencing the old store.
### 9. New content coverage
Two things the classic engine never migrated, plus one rebuilt area:
* **Storefront scripts** (Script Manager) — the analytics tags, chat widgets and tracking snippets installed on your storefront now migrate.
* **Customer segments** — shopper segmentation now migrates, and promotions that target segments keep working.
* **Store & storefront settings, rebuilt** — the classic app migrated many settings; V2 rebuilds this as a declarative, per-setting replica across roughly two dozen setting groups (store profile, currencies, tax, shipping, SEO, search filters, robots, security and more), each individually selectable, each applied per storefront where BigCommerce supports it, and each reported as copied, skipped, or failed — so you know precisely what carried over.
### 10. Selective migration, rebuilt
Pick exactly what you want to move across six tabs — **Products, Categories, Pages, Promotions, Themes, and Page Templates** — with search and filters, and dependencies come along automatically: selected products bring the brands and categories they reference (including parent categories, so the tree stays intact); selected pages bring their parent pages; picked themes can be activated on the destination storefront of your choice. Selected items that already exist on the destination are **updated**, not duplicated.
See [Selective content migration](/vortex-apps/staging-pro/selective-content-migration) for the full walkthrough.
### 11. Migration history that never disappears
Every migration's outcome — its summary, per-phase results, and the full item-level issue log — is preserved permanently, independent of the machinery that ran it. Open a migration from six months ago and see exactly what happened, down to the individual product that was skipped and why. See [History and rollback](/vortex-apps/staging-pro/history-and-rollback).
### 12. Built-in safety rails
These protections are enforced on every migration, in the app and over the API:
* A store can never be migrated onto itself.
* A store marked **Production** can never be a migration *destination*.
* **Make Exact Copy** is refused against production stores (it deletes data).
* Migrating orders, customers, or gift certificates requires **customer-data anonymisation** — personal details never land on a staging store in the clear.
## What "agentic" actually means
You may see StagingPro V2 described as "agentic." In plain terms, that simply means the app can now:
* **Spot and fix common migration problems on its own** (Auto-Heal), instead of stopping and waiting for you.
* **Keep you posted in real time**, with a live stream and plain-English reasons.
* **Recover by itself** if something is interrupted, picking up from the last checkpoint.
You are always in control. You choose exactly what migrates, which conflict strategy to use, and when to start, pause, or cancel. Nothing runs without you.
## Now included, free — your Vortex IQ AI toolkit
StagingPro is one of the [Vortex Apps](/vortex-apps/overview) inside the Vortex IQ **AI Operating System for ecommerce**. With V2, the rest of that toolkit is switched on for your account at no extra cost — all in the same login:
Automatic health checks across your storefront — find what's holding performance back.
Sessions, conversion, AOV and cart abandonment in one place — compare before and after any staging push.
Clear, scheduled reports such as Daily Revenue Leakage and Checkout Conversion Failure, delivered by email.
Ask questions about your store in plain English — "did the last StagingPro deploy succeed?"
**Get a store health report in your inbox.** Vortex Mind can email you a clear, plain-English report on what's working, what needs attention, and what changed. It's on by default, once a week — switch it to daily, or turn it off, anytime under **Settings → Notifications**. See [Notifications: email, Slack, Teams](/vortex-apps/staging-pro/notifications-email-slack-teams).
## The new public API
V2 introduces a brand-new REST API, so your team can drive migrations from scripts, CI pipelines, or your own tooling — everything the app does, programmatically.
**Base URL:** `https://app.vortexiq.ai/v2/api/bc-migration`
**How access works.** Your organisation is issued a single API credential (a client ID and secret) by Vortex IQ. You exchange it — together with your registered name, email, and organisation name — for a **bearer token** valid for 10 days:
```json theme={null}
POST https://app.vortexiq.ai/v2/api/bc-migration/login
{
"username": "Jane Merchant",
"email": "jane@example.com",
"organization_name": "Example Retail Ltd",
"client_id": "viq_bcmig_...",
"client_secret": ""
}
```
The login response includes your connected stores and their store hashes — the identifiers you use on every other call. You then send the token on each request (`Authorization: Bearer `). You **never** handle BigCommerce API tokens: stores are referenced by hash, and credentials are resolved securely on our side.
**What the API covers:** creating bulk and selective migrations, entity counts and forecasts, live progress streaming, the per-item issue log, permanent history, and pause / resume / cancel / verify. All the safety rails above are enforced on the API too.
To have an API credential issued for your organisation, contact your Vortex IQ account manager or [support](https://www.vortexiq.ai/contact-us).
## What this means for you
* **Your existing workflows keep working.** The entities you migrate today — catalogue, customers, orders, coupons, promotions, themes, pages, widgets, settings, multi-storefront channels — are all covered in V2.
* **You don't need to do anything to keep working today.** When your organisation is enabled for V2, Store Migration appears in your Vortex IQ workspace as StagingPro v2; your BigCommerce stores connect the same way they always have.
**A few capabilities stay on the classic app for now** — B2B Edition data migration, scheduled (future-dated) migrations, and the backup & restore subsystem. If you rely on these, keep using classic for those tasks; they are unchanged. Everything else is covered in V2.
## Getting started
Sign in at app.vortexiq.ai and look for **StagingPro v2** in the left menu. Everything is already connected.
New to the workspace? Plan your environments and run your first migration, step by step.
Environment list, status, and live migration progress explained.
Common questions, BigCommerce API limits, and what's on the roadmap.
Questions, or want V2 enabled for your organisation? [Contact us](https://www.vortexiq.ai/contact-us) — we'd love to walk you through it.
***
*StagingPro is part of the Vortex IQ AI Operating System for ecommerce.*