If you’re a Salesforce admin or developer, you know how challenging–not to mention time- consuming– a Salesforce org migration can be. And, just when you thought you were in the clear, a new org migration emerges–this time to Salesforce Hyperforce, the new infrastructure architecture for the public cloud. With Hyperforce, customers can deploy their instances over public clouds like AWS, Azure, and GCP, breaking down geographical barriers around data residency and compliance requirements.
Fortunately, a Salesforce Hyperforce migration doesn’t have to send you into an organizational tailspin if you properly prioritize data protection. In this blog, we’ll break down how to prepare for your Salesforce Hyperforce migration, while avoiding common migration risks.
A successful Salesforce Hyperforce migration depends on the work done before the actual migration. You and your team must take precautionary measures and extra steps to ensure a seamless migration. For example, some mandatory requirements include removing hard-coded instance references and hard-coded IP allowlists, using .NET version 5.0 or higher for Streaming Clients and Platform Events, and including a Service Name Indicator (SNI) for HTTPS handshake success. (And, the list goes on, depending on your unique org requirements.) If any of these technical steps are missed or overlooked, they can cause errors or problems ranging in severity and could result in data loss or corruption. Therefore, it’s critical that you do your homework before the migration or risk irreversible data issues.
During the actual migration, which (on average) takes around three hours, your org will be on ‘read-only mode’. That means all of your integrations will need to be turned off and then turned back on once the maintenance window has closed. But, if you aren’t careful, turning the lights on in your Salesforce org post-migration can feel like you're in the dark. If there are dependencies between integrations that affect data integrity and they are not restored in the right order, you could be facing data loss and corruption. It’s up to you to pause all integrations to your Salesforce orgs during the migration period. This also means that you’ll be responsible for re-connecting them after being onboarded in Hyperforce and ensure that the docking mechanisms are correct to avoid any data corruption scenarios.
Running a Salesforce batch job, much like an org migration, involves moving a large volume of data. A batch job is unique in that it moves data in manageable chunks at different times to stay within platform limits, and helps perform specific tasks on a large number of records.
When the time comes to migrate to Hyperforce, you must pay close attention to your batch jobs. Batch jobs that complete (or are set to complete) after the migration window can leave the data in an incorrect state, creating an organizational mess you’re left to clean up.
Your production instance has been invited to the Hyperforce migration party. Unfortunately, the invitation doesn’t entirely extend to your sandbox instances. If you have multiple sandbox instances, you must ensure they don’t refresh during the migration, and develop a strategy to recreate them, or risk losing the hard work and innovation that happened inside them.
An org migration, like one to Salesforce Hyperforce, has a lot of moving parts. Even the most meticulous teams can find themselves up against data loss or corruption incidents that slipped through the cracks during the process.
While this new migration requirement may be out of your control, there is an important element that you can control: your data protection efforts, starting with a regular backup of your data. Before you migrate to Hyperforce, we recommend that you conduct a manual point-in-time backup to crystalize your data pre-migration, in case something happens during the actual event. And, as a data protection best practice, it’s crucial to have a backup solution in place before, during and after your migration to ensure that you’re always on the protection offensive.
When sourcing a backup solution, you’ll want to be discerning about both backup and recovery capabilities. Your third-party solution should allow you to backup daily, monitor data changes, compare backups with previous backups, and completely recover Salesforce data, metadata, attachments, and even sandboxes. This way, you can have a transparent, real-time overview of what is going on with your data while knowing how fast you can bounce back in the event of data loss or corruption.
Business risk is high during an org migration, so it's critical to have a comprehensive data protection solution in place before the migration is underway. With OwnBackup, you can have peace of mind that your data is protected throughout the course of your Hyperforce Migration, supported by automatic, stress-free backup and recovery services. And, with our precision repair capabilities, you can go back in time to restore the exact data you need, without disrupting your records post migration.
While your experience with Salesforce Hyperforce is new, your experience with OwnBackup stays the same. OwnBackup is built 100% natively to Salesforce, meaning all our products will be available on the new platform. And, you’ll still get the same best-in-class service that we provide to our nearly 6,000 customers.
Request a demo today and learn how we can help you make a seamless, protected transition to Salesforce Hyperforce.