Salesforce’s evolution of OmniStudio marks a significant shift for customers using Vlocity Industries. What was once tightly coupled to a managed package runtime is now moving toward a standardized, platform-native OmniStudio runtime — bringing better tooling, performance, and long-term support.
But make no mistake: this is not a simple upgrade. It’s a runtime and data model migration that requires planning, testing, and the right tooling.
This post walks through what the OmniStudio Standard Runtime is, why Salesforce is pushing this migration, and how to approach it safely and successfully.
What Is the OmniStudio Standard Runtime?
Historically, OmniStudio (formerly Vlocity) ran on a managed package runtime with a custom data model. Components such as OmniScripts, FlexCards, Integration Procedures, and DataRaptors lived on objects like:
vlocity_cmt__OmniScript__c
vlocity_cmt__VlocityCard__cThe OmniStudio Standard Runtime moves these components onto Salesforce standard objects and a native execution model, aligning OmniStudio with the rest of the Salesforce platform.
Key differences at a glance
| Area | Managed Package Runtime | Standard Runtime |
|---|---|---|
| Data model | Custom (vlocity_cmt__*) | Standard Salesforce objects |
| Tooling | Vlocity Build Tool | Salesforce CLI |
| Designer | Legacy wrappers | Standard OmniStudio Designer |
| Feature velocity | Slower | Faster, Salesforce-native |
| Long-term support | Limited | Strategic direction |
This shift allows Salesforce to deliver new features faster while giving customers better alignment with standard DevOps, metadata, and platform tooling.
Why Salesforce Is Pushing This Migration
Salesforce is clearly positioning Standard Runtime as the future of OmniStudio. The reasons are both technical and strategic:
- Improved performance and scalability
- Better compatibility with Salesforce CLI and CI/CD
- Simpler metadata management
- Access to new OmniStudio features
- Reduced technical debt from legacy runtime dependencies
In short: staying on the managed runtime means falling behind.
Important Clarification: This Is a Migration, Not an Upgrade
This migration:
- Does not move data to another org
- Does not automatically refactor custom logic
- Does not guarantee 100% compatibility
Instead, it converts OmniStudio metadata from managed-package objects to standard objects and switches how that metadata is executed at runtime.
That’s why Salesforce provides a dedicated tool: the OmniStudio Migration Assistant.
The OmniStudio Migration Assistant (OMA)
OMA is a Salesforce CLI plugin designed specifically for this migration. It automates much of the work and enforces a structured approach.
Two execution modes
# install the plugin
sf plugins install @salesforce/plugin-omnistudio-migration-tool@2.0.0-rc.57
# execute asset
sf omnistudio:migration:assess -u paulo.orquillo@myorg.com
# execute migration
sf omnistudio:migration:migrate -u paulo.orquillo@myorg.com -a - Assess Mode
- Scans your org
- Identifies unsupported components
- Flags required manual changes
- Generates a readiness report
- Migrate Mode
- Converts eligible components
- Creates standard-runtime equivalents
- Produces detailed migration logs
Key rule: You should never run migration until the assessment report is clean or clearly understood.
Recommended Migration Approach
Phase 0: Preparation and Planning
Before touching the CLI:
- Inventory all OmniStudio components
- Identify:
- OmniScripts
- Integration Procedures
- DataRaptors
- Calculation Procedures
- Custom LWCs
- Apex Classes
- Enable OmniStudio Metadata API in the org
- Set up Salesforce CLI with proper permissions
- Choose a development sandbox as the first migration target
Skipping this phase is the most common reason migrations fail.
Phase 1: Development Sandbox Migration
This is where the real work begins.
Steps:
- Install the OmniStudio Migration Assistant
- Run Assess mode
- Fix reported issues
- Re-run Assess until results are acceptable
- Run Migrate mode
- Review generated reports and logs
At this stage, expect:
- Some components to migrate cleanly
- Some to require manual refactoring
- Some to remain unsupported
That’s normal.
Manual Refactoring examples:
- Apex Remote Action classes used in Omniscripts or Integration Procedures implements the VlocityOpenInterface needs to change to System.Callable.
# from
global with sharing class decodeAttachmentBody implements vlocity_cmt.VlocityOpenInterface
# to
global with sharing class decodeAttachmentBody implements System.Callable
If the custom LWC are not working, make sure that the setting is enabled in the Setup > Omnistudio > Deploy Custom Lightning Web Components in Standard Runtime
Phase 2: Testing and Validation
Once components are migrated:
- Deploy to a QA or UAT sandbox
- Perform full regression testing
- Validate:
- OmniScript navigation and data handling
- Integration Procedure inputs/outputs
- FlexCard rendering
- Experience Cloud pages
- Compare behavior with the managed runtime
This phase often uncovers subtle behavioral differences, especially in error handling and UI rendering.
Phase 3: Production Rollout
Production should be boring — if you’ve done the earlier phases correctly.
- Prepare production org with the same prerequisites
- Deploy via Salesforce CLI or CI/CD
- Validate key user journeys
- Disable Managed Package Runtime
- Enable Standard Runtime settings
Once flipped, there’s no rolling back without effort, so timing and confidence matter.
Common Pitfalls and Manual Work
Not everything is automated. Expect manual intervention in these areas:
- Angular OmniScripts – must be rebuilt
- Calculation Procedures – often need migration to Business Rules Engine
- Custom LWCs – may require namespace and deployment updates
- Reserved variable names (
request,response) – can break Integration Procedures
Planning time for this work is critical.
Post-Migration Best Practices
After migrating:
- Standardize OmniStudio deployment via CLI
- Retire legacy Vlocity build processes
- Update team documentation and runbooks
- Train developers on standard runtime patterns
- Monitor performance and error logs closely
This is a great opportunity to modernize your OmniStudio delivery model.
Final Thoughts
Migrating from Vlocity Industries to OmniStudio Standard Runtime is not optional — it’s inevitable. But with the right approach, it can be more than a technical necessity. It can be a platform modernization win.
Treat it as a structured migration, invest in assessment and testing, and leverage Salesforce’s tooling properly.
Done right, you’ll end up with a cleaner, faster, and more future-proof OmniStudio implementation.