Salesforce has deprecated the Vlocity managed package namespace in favor of the native OmniStudio namespace. If your org still runs on Vlocity, the migration is not optional — it is a matter of when, not if. This guide walks you through the process step by step.

Why the Migration Matters

• Better performance: Native components run faster than managed package equivalents
• Tighter platform integration: OmniStudio components interact directly with standard Salesforce features
• Continued support: Salesforce will eventually end support for the Vlocity namespace
• New features: Innovations like Agentforce and Data Cloud integrations are OmniStudio-native only

Pre-Migration Assessment

Before touching anything, you need a complete inventory of your Vlocity components. Document every OmniScript, FlexCard, DataRaptor, Integration Procedure, and any custom Apex or LWC referencing the Vlocity namespace.

Step 1: Enable OmniStudio in Your Org

Your Salesforce org must have the OmniStudio feature enabled. Work with your Salesforce account team to ensure the correct licenses are provisioned. You will need both the legacy Vlocity package and the new OmniStudio namespace active simultaneously during migration.

Step 2: Run the Migration Tool

Salesforce provides a built-in migration tool that handles the bulk of the conversion. Access it through Setup by searching for “OmniStudio Migration.” The tool migrates OmniScripts, FlexCards, DataRaptors, and Integration Procedures from the Vlocity namespace to OmniStudio.

Step 3: Fix What the Tool Cannot Migrate

The migration tool handles 80-90% of the conversion. The remaining 10-20% requires manual work:

• Custom Apex classes: Any Apex referencing vlocity_cmt or vlocity_ins must be manually updated
• Custom LWC imports: Lightning Web Components importing Vlocity modules need updated import paths
• Hardcoded namespace references: Check formula fields, validation rules, process builders, and flows
• Integration endpoints: External systems calling Vlocity-specific APIs need updated endpoints
• Turbo Extract behavior: Turbo Extracts may behave differently in the native namespace

Step 4: Regression Testing

This is where most migration projects fail. Teams run the tool, check that components open in the designer, and call it done. Your testing plan should cover:

• End-to-end OmniScript flows: Run every OmniScript with real data
• FlexCard data loading: Verify every FlexCard loads correct data
• DataRaptor accuracy: Compare outputs between old and new namespaces
• Integration Procedure callouts: Verify external integrations still work
• Performance benchmarks: Compare page load times against pre-migration baselines

Common Pitfalls

Pitfall	Impact	Prevention
Skipping the component audit	Missed dependencies break post-migration	Document every component before starting
Not testing with real data volumes	Performance issues in production	Test with production-equivalent data
Ignoring custom Apex references	Runtime errors after migration	Search entire codebase for Vlocity namespaces
Rushing UAT	Users discover issues in production	Allocate 2 full weeks for user testing

Timeline Expectations

For a typical mid-sized org (50-100 OmniStudio components), expect 6-10 weeks total: 1-2 weeks assessment, 1-2 days tool execution, 2-4 weeks manual fixes, 2-3 weeks testing, and 1-2 weeks UAT.

Mineffs: Your Vlocity to OmniStudio Migration Partner

At Mineffs IT Services, we specialize in Vlocity to OmniStudio migrations with deep expertise in both namespaces. Our team holds 22+ active Salesforce certifications with 6-7+ years of hands-on implementation experience across telecom, financial services, healthcare, insurance, and energy verticals.

Get in touch today to discuss how we can help with your next Salesforce project.