Data migration is never easy, but it can be especially difficult when moving to an Oracle SaaS environment using only the tools provided by Oracle. A better, easier way is to use tools from third parties right from the start of your implementation.
But which data migration tools are best suited for your specific migration use cases? Answering this question isn’t easy, either.
To help, we’ve outlined the five major use cases of migrating to an Oracle Fusion Cloud. For each, we’ve also provided a short list of recommended data migration tools. These recommendations are based on our experiences with real-world users. However, this is not a detailed rating. Basically, if a tool can perform all tasks needed for a specific use case, we’ve included it.
After some consideration, we narrowed our recommendations to just four tools: ChainSys, ConfigSnapshot, Datalynx and Rapid4Cloud. All four meet a pair of important criteria: They accelerate your migration to Oracle SaaS, and they’re available for licensing.
Here are the five main use cases when migrating to Oracle SaaS, and our recommendations for the data migration tools that can help you.
Use Case #1: Migrate business data from legacy to SaaS
During migration projects and later deployments to new business units, you’ll need to upload your existing business data from customers, suppliers and others into your Oracle SaaS environment. Ideally, you’ll do this with automation. This will save serious time and effort. You could need many iterations, and the volume of data will likely be considerable.
One recent and promising trend in this area is the growing use of Microsoft Power Query combined with Microsoft Power Automate. These tools are already familiar to many end users, and they can be operated with relative ease by non-IT staff.
Your Oracle implementation partner should be able to help with migration scripts based on Oracle HDL for human-capital management and Oracle FBDI for file-based data. These are helpful enough that you should negotiate with your implementation partner so you can keep them even after your migration is completed.
Fortunately, Oracle’s E-Business Suite (EBS) is well supported as a legacy source application. In our surveys, we found that three data migration tools provide out-of-the-box support for EBS as a source application: Datalynx, Rapid4Cloud and ChainSys. (ConfigSnapshot does not support business data migrations.)
These three tools also offer a no-code capability that’s useful during the Transform and Load stages of migration. This is important. In most SaaS-migration projects, these two stages account for up to 80% of the overall effort.
Use Case #2: Migrate setup data from legacy to SaaS
Your legacy applications contain important setup data. By re-using this data, you can jumpstart the configuration of your Oracle SaaS environment.
While Oracle’s Rapid Implementation spreadsheets can be helpful here, you’ll still need to populate them based on your existing environment. As of now, those spreadsheets cover only a limited number of configuration steps.
ChainSys, ConfigSnapshot and Rapid4Cloud can help you handle setup migration. They support Oracle ESB as a source system, and they give broad coverage for organizational setups. If your source is not EBS, they can help you use simple Excel-based templates to speed your setup.
Security issues come into play here. Both Rapid4Cloud and ChainSys run on host servers, adding an external security risk. By contrast, ConfigSnapshot is installed on the user’s PC, which should already be secured.
Use Case #3: Migrate data from one SaaS to another
Some organizations have to regularly move setup data from one Oracle Fusion SaaS environment to another. This is a common use case in complex organizations where new business units are added regularly. Setup data must also be transported when moving from development to staging and production environments.
Whenever your SaaS vendor issues an upgrade, you can use third-party tools to compare your staging and production environments, do impact analyses and steer regression testing. Some organizations combine the XML output from these tools with their uploaded configuration files.
Overall, we found that two tools support the SaaS-to-SaaS use case very well: ConfigSnapshot and Rapid4Cloud.
Use Case #4: Archive legacy data
Even after you’ve successfully moved to Oracle SaaS, you’ll still need to take care of your legacy data. That’s an important move demanded by most regulators and auditors. This is a long-term commitment. Depending on your industry, you might need to keep legacy data archived for more than a decade.
However, once you’ve migrated to SaaS, you’ll want your legacy systems to be decommissioned. How do you do this while simultaneously keeping that data archived?
We have found that a particularly good tool for this use case is Datalynx. It lets you upload a reasonable amount of historical data to Oracle SaaS—say, five years’ worth—while leaving the rest in archives.
There’s also another option: You can keep the legacy environment alive for records maintenance. But compared with using Datalynx, this is much more expensive.
One extra note: If you also need to archive Oracle EBS setup data, you may need to supplement Datalynx with ConfigSnapshot. Together, they can archive both types of data.
Use Case #5: Archive SaaS data
What will you do if your Oracle SaaS is the subject of a ransomware attack? Granted, that is unlikely to happen. But if it does, do you have a Plan B for regaining access to your critical business data?
It makes sense to periodically export your data to a safe place outside the Oracle data center. This can be done on a monthly, quarterly or annual basis.
If you haven’t yet started your SaaS implementation, you’d be wise to check first with your regulatory and financial auditors. Learn what they require in the way of archiving and records management. Then incorporate that into your archiving strategy.
It also makes sense to have a long-term exit strategy. The day may come when you’ll want to exit the Oracle cloud. Having a plan for that move makes sense, too.
When it comes to extracting business data, we have found that three tools do this quite well: ChainSys, Datalynx and Rapid4Cloud. Still, you’ll need to work with your DevOps team to ensure that the extracts are automatically initiated on scheduled points in time and then uploaded to a backup environment outside the Oracle data center.
Make sure to test this setup, probably on an annual basis. To run a test, you’ll need to restore data from your archive and then upload it into your staging SaaS environment. If it all runs normally, your Plan B is approved.
Address security and vendor lock-in concerns
No matter which use case you implement and which third-party tools you use, you’ll still need to think about security. Most likely, you’ll be moving highly sensitive business data, such as personnel records and salary information. This data needs to be kept safe and secure. Depending on your location, you may also need to comply with regional privacy laws such as the European Union’s GDPR.
However, once your data resides in another company’s cloud, you’ve also increased your potential attack surface. That’s the case with Oracle SaaS, and it’s also the case with several of the third-party tools we’ve recommended here.
Though the tool vendors will tell you their security is second to none, to keep your data safe and secure, you may want to encrypt and mask sensitive data during the Transform phase. Also, because some of the transformation will likely be performed by authorized members of your organization’s HR group, you may want to use tools that support low-code transformation. That way, you can avoid having to authorize other people to view the sensitive data. For this job, we found that ChainSys, Datalynx and Rapid4Cloud have low-code capabilities.
As for vendor lock-in, it isn’t really an issue until after you’ve completed your initial business-data migration. But you’ll need to consider it once you’ve moved to post-implementation setup and data management, aka configuration management.
If your environment is relatively simple, then Oracle’s out-of-the-box features, combined with some Power Query scripts, should suffice to maintain your configuration without creating additional vendor lock-in. But keep in mind that you likely will become dependent on one or two subject matter experts, and you may be in trouble if those SMEs become unavailable.
One good approach is to introduce a structured process for configuration management, support this process with a commercial tool and have it operated by a broader team. To further mitigate your dependency on any single tool vendor, ensure that your setup data is in a readable format, such as XML or JSON. That way, you can edit the data without having to use a third-party tool.
Need more help selecting a data-migration tool for your Oracle SaaS migration? Learn more about Oracle Enterprise Applications and SaaS.
About the author
Gert Vermeyen runs the global Oracle Cloud Applications offering of DXC Technology. A member of DXC’s Oracle practice, Gert has for many years helped customers to improve their businesses with Oracle cloud applications.