Separating a Global Salesforce Org to Protect Patient Data

A global medtech company moved its North America business onto a dedicated, US-hosted Salesforce org, then removed more than five million patient records from its global environment, without interrupting daily operations.

The client is a global medical technology company focused on developing innovative treatments for cardiovascular disease and neuromodulation disorders. Its portfolio spans cardiac surgery, neuromodulation for epilepsy, and sleep apnea therapy, and it operates in more than 100 countries.

Sensitive Data in a Shared Global Org

The client’s Salesforce Sales Cloud org was shared by every region. North American commercial data, including personally identifiable information (PII) and protected health information (PHI), sat on infrastructure outside the US. The company’s privacy and data residency policy has recently changed because of industry trend and customer demand.

The client set three goals for the separation:

At a medical device company, patient data rarely sits in one place. It shows up in patient records, insurance verifications, patient opportunities, and leads. Several factors made separation harder than a standard migration:

Smartbridge led the program with the client’s IT team and business users over roughly six months, from discovery through hypercare.

The technical work followed a proven sequence: metadata first, then data loaded in two waves, with a change freeze on production configuration. What set this project apart was that every step was planned around where patient data would go and who could see it once it got there.

Finding Where Sensitive Data Lives

Discovery covered the global org’s metadata, data volumes, files, integrations, and third-party apps. For compliance, the most valuable result was a list of the objects that held PHI data, along with the filters needed to separate North American records from everything else. The client signed off on those objects and filters, and the same list guided both the migration and the later removal of PHI from the global org.

Moving Only the Data That Belongs

Shared objects such as accounts, contacts, opportunities, and invoices were filtered by record type, and in some cases by market code, so only North American records were extracted. Non-US objects were excluded. Sensitive identifiers the North America business didn’t need, such as Social Security numbers on insurance verification records, were flagged for removal. Less data meant less exposure, and each load ran faster and was easier to verify

Migrating Metadata Iteratively

Salesforce components are highly interconnected and can’t always be migrated independently. Some components went first to establish foundational access, then were migrated again once downstream dependencies were in place. Profiles are a good example: basic object and field permissions came first, then page layouts, record types, Flows, Apex classes, and other application access were layered in.

The team validated that Apex test classes met code coverage requirements in the target org, and remediated hard-coded IDs, org-specific references, and legacy configuration. The cycle of sequencing, migrating, validating, remediating, and re-migrating continued until the new org matched the source org functionally.

Keeping PII Out of Uncontrolled Environments

Sandboxes are where regulated data is most often exposed during migration. A temporary sandbox in the global org was used to strip out EU-only items before anything was extracted. Smartbridge team members handled patient data only on client-managed infrastructure, and a data comparison tool used to reconcile source and target records was approved by the client’s IT compliance team before use.

Salesforce Shield for Data Privacy and Security

The new org was set up with Salesforce Shield to match the protection in the global environment, and Shield Platform Encryption was configured in the new production org as part of the production migration. During cutover, all North America users were deactivated in the global org and removed from its single sign-on group. The client audited and approved that access removal before go-live.

Validating in Two Phases

The same testers, drawn from strategic business units, ran both rounds of testing:

Executing a Controlled Cutover

Cutover ran from a checklist of about 60 activities, each with an owner and a scheduled date. North America users were set to read-only, a final delta load covering roughly 160 objects and their files was run, and licenses and single sign-on were switched to the new org. Integrations were smoke tested before users logged back in, and communications went out in several stages so users knew what to expect.

Removing Patient Data from the Global Org

Moving the data solved only half the problem: until North America patient records were removed from the global environment, they still sat on infrastructure outside the US. The client first verified the objects and filters. A backup of the data to be deleted was exported and stored offline in a secured location. The data was then deleted from the global production org, followed by its sandboxes. The removal covered 11 objects and more than five million records.

The separation gave the client a US-hosted North America Sales Cloud org that is compliant with company and regulatory requirements:

What This Means for Your Organization

If your Salesforce org is shared across regions, business units, or legal entities and holds data with specific residency requirements, separating it is more than a standard technical migration. Based on this engagement, here is what a successful separation requires:

If your organization needs to migrate or separate a Salesforce environment to meet data privacy or residency policy, contact Smartbridge. We’ll pair you with a senior expert to provide recommendations and guidance.

Keep Reading: Splitting a Salesforce Org