How to Migrate From Vlocity Managed Package to OmniStudio Standard Runtime

Salesforce has set April 3, 2028 as the retirement date for the OmniStudio Managed Package, Managed Package Runtime, and Managed Package Designer. If your Omniscripts, Flexcards, Data Mappers, and Integration Procedures still run under the vlocity_cmt, vlocity_ins, or vlocity_ps namespace, this migration is already on your roadmap with a published deadline. The good news is that the path is now well defined. Salesforce ships a command-line tool that handles most of the conversion, and its documentation lays out a 3-phase process that runs from a development sandbox to production.

The harder part is everything around the tool. Industry-specific objects, Angular components, calculation logic, test scripts, and deployment pipelines each need a plan of their own. This guide covers the full OmniStudio migration from start to finish. You’ll see what changes under the hood, how to pick the right path for your org, which commands to run, which blockers to expect, and which work still falls on your team after the tool finishes.

TL;DR

·  The OmniStudio standard runtime reads components from standard Salesforce objects such as OmniProcess and OmniDataTransform. The Vlocity package stores them in its own custom objects.

·  The OmniStudio Migration Assistant (OMA) is a Salesforce CLI plugin. Run it in Assess mode first, fix what it flags, and then run Migrate mode.

·  The work happens in 3 phases: development sandbox, validation sandbox, and production. Upgrade to the Winter ’26 package or later before you begin.

·  Some tasks stay manual, including Angular Omniscripts, calculation logic, industry-specific objects, OmniAnalytics, and UI test scripts.

·  Once you disable the Managed Package Runtime setting in production, the org locks into the standard runtime. Finish testing before you switch it off.

What the Vlocity Managed Package and OmniStudio Standard Runtime Are

Where the Vlocity Managed Package Came From

Vlocity built industry apps on top of Salesforce long before it became part of the company. Its products shipped as managed packages, each with its own namespace and its own custom objects for storing Omniscripts, cards, and data transforms. Salesforce closed its acquisition of Vlocity in June 2020 and later rebranded the business as Salesforce Industries. The company’s fiscal 2022 annual report filed with the SEC puts the fair value of the deal at roughly $1.4 billion, which shows how central these tools became to the Salesforce industry strategy.

The packages didn’t disappear after the deal closed. Communications, Media, and Energy customers kept using vlocity_cmt, insurers kept vlocity_ins, and public sector orgs kept velocity_ps. Salesforce also launched new industry clouds built on Vlocity technology within months, and later created an OmniStudio Foundation package for customers on products like Financial Services Cloud and Health Cloud. That history explains why so many orgs still run OmniStudio through a package today, with component definitions stored in custom objects such as OmniScript__c and DRBundle__c. Public Sector customers have a separate package deadline: Salesforce lists May 1, 2028 as the retirement date for the Vlocity Government PS Managed Package.

What the Standard Runtime Means

A runtime is the engine that loads and runs your OmniStudio components when a user opens a page. The managed package runtime lives inside the installed package. The OmniStudio standard runtime is built into the core Salesforce platform, so it needs no package at all. It reads component definitions from standard objects that every org already has, and it’s where Salesforce now builds new OmniStudio features. Beginning with Summer ’25, new customers get OmniStudio package-free, with the designers and runtime available natively through supported cloud licenses. Existing package customers have to migrate to reach the same place.

Why Salesforce Is Moving Everyone to the Standard Runtime

Salesforce has now published the end state. The OmniStudio Managed Package, Managed Package Runtime, and Managed Package Designer retire on April 3, 2028. In an August 2026 post on the Salesforce Developers Blog, the OmniStudio team also said its goal is to bring every customer onto the OmniStudio standard runtime. That makes the managed package a shrinking target. It still works today, but the features Salesforce is building, such as Integration Procedure actions for Agentforce and design assistance in the standard designer, are aimed at the standard runtime.

Performance is the most concrete benefit Salesforce cites. Based on its internal testing, the company reports that the standard runtime runs 2x to 5x faster depending on configuration, with Flexcards showing the largest gain. In those tests, execution averaged 2,112 ms on the standard runtime compared with 5,061 ms on the package runtime. Treat these as vendor benchmarks. Your results will depend on how your components are built and how many remote calls they make, so measure your own baseline before and after the move.

The operational case is just as strong for most teams. Standard components deploy through Salesforce CLI and the Metadata API like the rest of your org’s metadata, which retires the separate DataPack pipeline many teams maintain. The standard runtime also supports Lightning Web Runtime (LWR) sites in Experience Cloud, which matters if you plan to move customer portals to LWR. For many orgs, the deciding factor is simpler. Staying on the package means running a second, older toolchain while the rest of the platform moves on without it.

Timing still matters. Schedule the OmniStudio standard runtime move away from peak business periods such as renewal season or a major product launch, since those windows leave little room for regression fixes. One practical approach is to tie the project to a Salesforce release, so you upgrade the package, validate, and cut over within one release cycle. Starting early also gives you room to handle Angular components and calculation logic, which usually drive the length of the project more than the tool run itself.

Managed Package Runtime vs Standard Runtime: Key Differences

The 2 runtimes can look alike in the designer, but they differ in where data lives and how you deploy. The table below sums up the differences that affect migration planning, so you can see which rows will turn into work items for your team.

Salesforce keeps an official page on the differences between the managed package and standard versions of OmniStudio, and it’s worth reading line by line before you estimate anything. The key row for planning is the data model. The standard runtime works only with standard objects and doesn’t read the custom objects from the legacy packages. Almost everything else in this guide follows from that rule, since every component has to be rewritten into a new home before the standard runtime can load it.

Find Your Migration Path Before You Start

Your starting point decides which steps apply to you. Salesforce groups customers by 2 factors: the package they have installed and the data model their components use. Open Setup, check the installed packages list, and look at where your Omniscripts are stored. If they sit in OmniScript__c records under a vlocity namespace, you’re on the custom data model. If they sit in OmniProcess records, you’re already on the standard data model, even though the package runtime still renders them.

Some orgs sit between these states for a while. Salesforce supports an OmniStudio Hybrid setup where you can switch between the managed package designer and the standard designer to work through cross-dependencies before a full cutover. Components you create in the standard designer stay in that environment and can’t be opened in the package designer. Treat hybrid as a short transition state that helps you untangle dependencies, and set a date to leave it.

How the Custom Data Model Maps to the Standard Data Model

Migration rewrites records from one set of objects to another. Knowing the mapping helps when you read the assessment report, write SOQL queries for validation, or fix Apex that reads OmniStudio data directly. The main pairs are listed below, using the names Salesforce publishes for each object.

Integration Procedures live in OmniProcess alongside Omniscripts, with a field that marks each record’s type. Some names change along with the objects. DataRaptors are now called Data Mappers. Calculation Procedures and Calculation Matrices move out of OmniStudio entirely and into the Business Rules Engine, where they become Expression Sets and Decision Matrices. Keep a short glossary for your testers, because business users will still use the old names in bug reports for months.

The mapping also explains why custom code breaks. Any Apex class, LWC, or report that queries vlocity_ins__OmniScript__c will return nothing after migration, because the data now lives in OmniProcess on the standard data model. The OMA updates many of these references for you, as the next section shows. Code that builds object names at runtime or reads fields through strings can slip past it, though. Search your codebase for the namespace prefix before you start, so you know how much custom code touches the old objects.

What the OmniStudio Migration Assistant Automates and What It Doesn’t

The OmniStudio Migration Assistant is a Salesforce CLI plugin that converts your components to the standard data model and switches them to the OmniStudio standard runtime. It’s published on npm as the @salesforce/plugin-omnistudio-migration-tool package, where you can check the current version before you install it. Salesforce says the tool can cut manual migration effort by about 95%. That figure covers component conversion. It doesn’t include planning, testing, or the industry objects covered later in this guide.

The scope reaches past the core components. Along with Flexcards, Omniscripts, Data Mappers, and Integration Procedures, the OmniStudio Migration Assistant handles Omni Global Auto Numbers, Apex classes, FlexiPages, Experience Cloud site pages, Lightning web components, and custom labels that reference OmniStudio. That’s why the tool offers a –relatedobjects flag for code and pages. The manual rows in the table need a decision from a person, so they belong at the front of your plan.

Pre-Migration Checklist for Your Sandbox

Most failed runs trace back to a skipped prep step. Start by refreshing a sandbox from production, because you should never run the tool against a live org. Then turn on OmniStudio Metadata API support, a manual setting explained in Salesforce’s guide to enabling OmniStudio metadata, since standard components need it to deploy as metadata. Work through the rest of the list below before you run anything.

·   Upgrade the Vlocity package in every sandbox to Winter ’26 or later. Salesforce requires this no matter which path you’re on.

·   Confirm that licenses and permission set licenses for the standard runtime are provisioned for the users who’ll need them.

·   Build an inventory of components by type and version, and mark unused ones to retire instead of migrate.

·   Run your full automated test suite and record the results as a baseline for later comparison.

·   List every Apex class, LWC, and Experience Cloud page that references the package namespace.

·   Agree on a development freeze, or a process for tracking components built while the migration is underway.

·   If you’re on CME, check each component’s standard runtime certification status in Salesforce’s CME support list.

The inventory step pays for itself quickly. Large orgs often carry several inactive versions of the same Omniscript, and the -a flag tells the tool to include all versions. That adds run time and makes the assessment report longer to read. Decide early whether you need every historical version on the new objects, or whether a smaller set of active components is enough for your audit and support needs.

Set up the team before the first run. You’ll want an OmniStudio developer who knows the existing components to read the assessment report and fix what it flags. Pair that person with a QA lead who owns the regression suite and signs off each phase. An admin should own the settings changes and permission sets, since those steps are easy to miss in production. Give 1 person the final say on the cutover date. The OmniStudio Migration Assistant does the conversion, but someone still has to decide when the report is good enough and when to disable the old runtime.

Phase 1: Assess and Migrate in the Development Sandbox

Phase 1 is where the conversion actually happens. Salesforce’s help article on migrating from Vlocity Industries managed packages to the standard runtime breaks it into preparation, assessment, fixes, migration, and validation, all inside a development sandbox. Expect to run the assessment several times until every record is either Ready for Migration or Warnings, with no Failed or Needs Manual Intervention items, and build those loops into your schedule.

Install the Plugin

The OMA runs on Salesforce CLI, so install or update the sf CLI first and authenticate to your development sandbox. Then add the plugin. Salesforce’s current release guidance requires OmniStudio Migration Assistant 2.0.0-rc.59 or later. Versions change often, so confirm the latest supported rc version on the official Versions page before you install it.

sf plugins install @salesforce/plugin-omnistudio-migration-tool@2.0.0-rc.59

Run Assess Mode

Assess mode reads your org and produces a report without changing any data. The assessment report lists each component’s readiness and flags problems such as naming conflicts and Angular-based Omniscripts. Ready for Migration and Warnings can proceed. Failed and Needs Manual Intervention items must be resolved before Migrate mode. Point it at your sandbox user and add -a to include all component versions.

sf omnistudio:migration:assess -u dev_sandbox_user@example.com -a

You can narrow a run with the –only flag. Accepted values are dm for Data Mappers, ip for Integration Procedures, os for Omniscripts, fc for Flexcards, autonumber, and cl for custom labels. The –relatedobjects flag adds apex, lwc, expsites, and flexipage to the scan. Narrow runs help when you’re fixing 1 component type and want a quick recheck without waiting on the full report.

Run Migrate Mode

Run Migrate mode only when the assessment has no Failed or Needs Manual Intervention items. Records marked Ready for Migration or Warnings can proceed. What it moves depends on your OmniStudio Metadata setting. If that setting is enabled, the tool migrates only package dependencies. If it’s disabled, the tool migrates both your OmniStudio assets and the package dependencies. Salesforce says to run Migrate mode only once in a development sandbox. If you must rerun it, create a fresh development sandbox first.

sf omnistudio:migration:migrate -u dev_sandbox_user@example.com -a

After the run, review the migration report for any failed items. Then switch off the Managed Package Runtime and Managed Package Designer settings in the development sandbox. Rerun your baseline test suite and compare the results with the numbers you recorded earlier. Any difference needs an explanation before you move on to Phase 2.

Fixing the Blockers the Assessment Report Flags

Assessment reports tend to surface the same small set of issues across orgs. Fixing them before migration is always cheaper than fixing them afterward, so treat the absence of Failed and Needs Manual Intervention items as the gate for Migrate mode. Warnings can remain. These are the blockers you’re most likely to meet.

Duplicate Data Mapper Names

The standard runtime doesn’t allow special characters such as underscores in component names. When the tool strips those characters, 2 Data Mappers can end up with the same name. For example, Get_Account_Info and GetAccount_Info would both become GetAccountInfo. Rename one of them, update every Integration Procedure and Omniscript that calls it, and then rerun the assessment to confirm the conflict is gone.

Reserved Keywords in Integration Procedures

Integration Procedures that use reserved words like response, request, or action as variable names will fail assessment, because the standard runtime doesn’t accept them. Rename each variable and trace every merge field that reads it. A missed reference won’t raise an error in the designer. It only shows up later as missing data when the procedure runs, which makes it hard to trace in testing.

Angular Omniscripts

The OMA can’t convert Angular Omniscripts. You’ll need to convert each Angular Omniscript to an LWC Omniscript by hand, test it on the package runtime, and only then run Migrate mode. Custom Angular templates don’t carry over, so any custom styling or behavior has to be rebuilt in LWC. For orgs with a large Angular footprint, this is often the biggest single line item in the whole plan.

Calculation Procedures and Calculation Matrices

Calculation logic has to leave OmniStudio before migration. Salesforce documents how to move Calculation Procedures and Calculation Matrices into the Business Rules Engine, where they become Expression Sets and Decision Matrices. Update any Integration Procedure that calls the old calculation actions, then test pricing or eligibility outputs against known inputs. Small rounding or ordering differences can change a quote, so compare results record by record.

Custom functions are easier. Starting with Summer ’25, when you migrate and turn off the package runtime, OmniStudio converts custom functions written in the user-defined syntax to the standard syntax automatically. Review the converted functions in your Data Mappers and Integration Procedures anyway. They often hold business logic that nobody has documented, and a quick read now saves a slow debug later.

Validation and Production Cutover

Phases 2 and 3 move tested work forward instead of rerunning the full conversion. Salesforce’s December 2025 walkthrough of the migration phases describes validation as the final check before production. It’s also the phase teams most often squeeze when deadlines slip, and cutting it short is where most go-live problems start.

Phase 2: Validation Sandbox

Deploy the migrated components from development to a clean test sandbox, then run full regression testing across every business process that touches OmniStudio. If you started on the Vlocity package with the standard data model, you run the OMA in this phase only for Omni Global Auto Numbers. Everything else moves through standard deployment tools such as Salesforce CLI or VS Code. Foundation package orgs skip the OMA here entirely, since Omni Global Auto Numbers don’t exist in the omnistudio namespace.

Phase 3: Production

Production prep starts with enabling OmniStudio Metadata API support and assigning the right permission set licenses and permission sets to users. Deploy the components you validated, switch off the Managed Package Runtime and Managed Package Designer settings, and run post-deployment checks on your most important flows first. Plan the cutover for a low-traffic window, and brief your support team on what users might notice on day 1.

Why You Can’t Easily Go Back

Disabling the Managed Package Runtime setting is a one-way door. Salesforce’s hybrid documentation notes that the system locks into standard runtime mode once that setting is off, to keep metadata stable. Your rollback plan can’t rely on switching the setting back on. Build it around fixes on the OmniStudio standard runtime instead, and keep the package installed. Salesforce advises against uninstalling it, because existing workflows and custom components may still depend on package schema or metadata.

Checks for the First Weeks After Go-Live

Watch the first weeks closely. Compare load times for your busiest Omniscripts and Flexcards with the baseline you recorded, since that’s the clearest proof the OmniStudio standard runtime is doing its job. Review debug logs and Integration Procedure errors daily at first, and track support cases that mention broken forms or missing data. Keep a short list of custom code that still references package objects, and work it down. Once things settle, run the OmniStudio Migration Assistant in Assess mode against any new work to confirm nothing was built on the old model.

Planning for the Work the Tool Won’t Do

The OMA converts OmniStudio components, and your data design stays your responsibility. Salesforce’s own architects name industry objects as the item teams underestimate most. Objects that came with the Vlocity packages, such as those behind CME order management or insurance policy models, aren’t moved to standard objects by the tool. Migrating that data is a separate project with its own mapping and testing, and the options depend on which Salesforce Industries cloud you license.

Components Built During the Migration

A large migration can run for weeks once you count fixes and regression testing. If developers keep building in the package designer during that time, they create new components on the custom data model that will also need to move. Either freeze package development, or keep a running list and run a final assessment against everything bound for production before go-live.

OmniAnalytics and Tracking Data

If you use OmniAnalytics, the data moves to a new home. On the package runtime, it’s stored in the tracking entry custom object for your namespace. On the standard runtime, OmniAnalytics stores events in the Decision Explainer service, so dashboards and reports built on the old object will need to be rebuilt. Decide how much historical tracking data you need, and export it before cutover.

UI Test Automation and Custom Pages

Automated UI tests are easy to forget until they fail. HTML element tags differ between the 2 runtimes, so Selenium or UTAM scripts written against package components will break. Budget time to update locators. Also review Lightning pages and Experience Cloud sites that load Omniscripts or Flexcards through custom LWCs. After the switch, edits won’t appear on those pages unless you replace them with standard components or enable the Deploy Custom Lightning Web Components setting.

Deployment After Migration: Replacing the Vlocity Build Tool

Your release process changes the day you go live. On the Vlocity package, most teams moved OmniStudio components with the Vlocity Build Tool or IDX Workbench, exporting DataPacks as JSON and deploying them apart from the rest of the org’s metadata. On the OmniStudio standard runtime, components are metadata. You retrieve and deploy them with Salesforce CLI and source tracking, the same way you handle flows and Apex.

That shift simplifies pipelines, but it takes rework up front. CI jobs that call packExport and packDeploy need replacing, and your source repository will change shape, since components now live as metadata files instead of DataPack folders. Make a clean baseline commit right after the production OmniStudio migration so your history starts from a known state. Any custom scripts that compared DataPacks will need new equivalents that work on metadata files.

Review permissions at the same time. Deployment users need access to OmniStudio metadata types, and your CI user may need new permission sets. Test a full deployment from a feature branch to a sandbox before the first real release on the standard runtime. That way, your first production deploy after cutover isn’t also the first test of the new pipeline.

Conclusion

Moving from the Vlocity managed package to the OmniStudio standard runtime is a planned platform change, and Salesforce has made its direction clear. The OmniStudio Migration Assistant handles most of the component conversion, but the result depends on the work around it. Start with a clean inventory and an honest scope for industry objects and Angular components. Treat the assessment report as your source of truth and loop until no Failed or Needs Manual Intervention items remain. Warnings can proceed to migration. Then test the way your users actually work. Don’t disable the package runtime in production until validation passes. Teams that plan this way end up on a faster runtime with 1 deployment pipeline for all their metadata.

FAQs

What is the difference between the Vlocity managed package and the OmniStudio standard runtime?

The Vlocity package runs OmniStudio components through an installed package that stores them in its own custom objects. The OmniStudio standard runtime is built into the Salesforce platform and reads components from standard objects such as OmniProcess and OmniUiCard. It needs no package and deploys through standard Salesforce tools.

Is Salesforce retiring the Vlocity managed package?

Yes. Salesforce will retire the OmniStudio Managed Package, Managed Package Runtime, and Managed Package Designer on April 3, 2028. New customers have been package-free since Summer ’25. Salesforce separately lists May 1, 2028 as the retirement date for the Vlocity Government PS Managed Package used by Public Sector customers.

What is the OmniStudio Migration Assistant?

It’s a Salesforce CLI plugin that assesses your org and then converts OmniStudio components to standard objects and the standard runtime. It runs in Assess mode, which only reports, and Migrate mode, which makes the changes. It also updates related Apex, LWCs, pages, and custom labels.

Which package version do I need before I migrate?

Salesforce says to upgrade the Vlocity Industries managed package to Winter ’26 or later before starting. This applies to every transition path. Upgrade every sandbox you’ll use in the migration, including the validation sandbox.

Can the migration tool convert Angular Omniscripts?

No. Angular Omniscripts must be converted to LWC Omniscripts by hand before you run Migrate mode. Custom Angular templates also need to be rebuilt in LWC, so scope this work early.

What happens to Calculation Procedures and Calculation Matrices?

They move to the Business Rules Engine, where they become Expression Sets and Decision Matrices. This is a manual step that should happen before you run Migrate mode. Test the outputs against known inputs afterward.

Can I roll back after disabling the Managed Package Runtime setting?

Plan as if you can’t. Salesforce documents that the org locks into standard runtime mode once the setting is disabled. Base your rollback plan on fixing issues within the standard runtime instead.

Should I uninstall the Vlocity package after migrating?

Salesforce doesn’t recommend it. Existing workflows and custom components may still depend on the package schema or metadata. Keep it installed unless Salesforce guidance for your cloud says otherwise.

How long does an OmniStudio migration take?

It depends on component count, Angular usage, industry objects, and test coverage. Salesforce architects note that a large migration can take a few weeks once manual fixes and regression testing are included. Industry object migration can add much more time on top.

Will my own custom objects still work on the standard runtime?

Yes. The standard data model includes standard objects and custom objects you build on the platform. The limit applies to the custom objects that shipped inside the Vlocity packages, which the standard runtime doesn’t use for component definitions.

How do I deploy OmniStudio components after migration?

You deploy them as metadata with Salesforce CLI or other Metadata API tools. The Vlocity Build Tool and DataPack exports are no longer part of the process. Update your CI jobs and repository layout to match.

What happens to my OmniAnalytics data?

On the standard runtime, OmniAnalytics stores event data in the Decision Explainer service instead of the package tracking object. Reports and dashboards built on the old object need rebuilding. Export any history you want to keep before cutover.

Does the migration tool move industry-specific objects?

No. Objects from the CME, Insurance, or Public Sector packages aren’t converted automatically. Treat their migration as a separate data project with its own mapping and testing.

Will my automated UI tests break after migration?

Many will. HTML element tags differ between the 2 runtimes, so scripts that target package components need updated locators. Rerun and repair your test suite in the development sandbox.

Is the standard runtime really faster?

Salesforce’s internal tests show execution 2x to 5x faster depending on configuration, with averages of 2,112 ms versus 5,061 ms. Real gains vary by how your components are built. Measure a baseline before migration so you can compare.