cancel
Showing results for 
Search instead for 
Did you mean: 
JeffW
Employee Alumni
Employee Alumni

Introduction

If you are thinking about migrating to the Incorta Cloud from an existing on-prem Incorta installation this article will help you get started and guide you through the steps and key decision points you will have to make prior to and during the migration process.  After reading this article, if you feel you are interested in potentially migrating to the cloud, please contact your Account Executive or Incorta to begin the process.

What you need to know before reading this article

Let's Go

Pre-migration Information and Decisions

Before migration to the cloud, there are a number of pre-migration data points and decisions that must be made before undertaking the migration itself.  Typically, your Incorta Account Executive, or Customer Solutions, or in some cases, Incorta Support will be working with you to accomplish this task.  They may ask you a few questions beforehand that will guide the migration process.  Some of these questions include:

  1. What version are you currently running.  Your new Incorta cluster will be the most current Incorta version.
  2. How much data is to be loaded?  This will ensure the correct sizing of your Incorta Cluster has been provisioned.
  3. How many environments do you require (Dev, UAT, Prod?)
  4. Which Data Connectors are you using?
  5. Is a Full Load of your data possible, or will you require your current data to be copied to the cloud?
  6. Are you using SSO for authentication, or LDAP synchronization for Users and Groups?
  7. Have you implemented custom branding with logos, fonts and color schemes?

This list is not all inclusive of the questions you will be asked, but they are important, as they will inform the complexity of the migration to the cloud.  Once this information has been gathered, a plan can be put in place for performing the migration.

Data Agent: What is it and why is it needed?

You are embarking on a process to migrate your data and reporting to the cloud.  Up until now, Incorta has been operating within you corporate network, inside the firewall to the public network, and within full control of your network and server engineers.  Incorta has been set up with one or likely many data connections to various data sources that are located both inside and outside your corporate network.  For example, you may be running Oracle EBS in house, or you may have your own Oracle databases for other applications on various servers within your network, or you may be using other SaaS services like Salesforce which is located in the Public network, but is accessed by you from your private network.  

Well, when you move to the cloud, your Incorta "servers" will be living in the cloud but they will still need access to your internal data sources.  The Data Agent (DA) is a small Incorta program that runs on a server within your network that is responsible for both communicating with your Incorta cloud on a secure channel over the public network, but also for firing off data requests to your data sources and packaging them up to be sent to the cloud for loading.  The DA link provided above provides a much more detailed explanation of this, and you are encouraged to read that article to familiarize yourself with the Data Agent. 

Incorta Migration Execution

The steps taken to actually perform the migration from your on-premises Incorta environment to the cloud will generally follow the steps listed below:

  1. Verify Cloud Cluster is adequately sized and update if necessary based on sizing from the pre-migration questionnaire taking into account what you, the customer, have contracted for.
  2. If you are upgrading from a prior version of Incorta, perform any of the pre-upgrade tasks outlined in the documentation.  This typically includes such things as running the Inspector Tool and fixing any SEV-1 issues prior to your migration to the cloud.
  3. Export the Tenant from the on-premises environment via the on-premises CMC.
  4. Import the Tenant using the CMC in the Cloud.
  5. Request the Tenant \Data directory containing all customer flat files (csv, xls, txt, etc) that are used as local data sources be copied from on-premises to the cloud GCS location for the cluster.  The Incorta Cloud team will perform this task in conjunction with Support and the Customer.
  6. If full loads are not possible and your data must be copied from on-premises, request the data to be copied from on-premises to the Cluster GCS location. The Incorta Cloud team will perform this task in conjunction with Support and the Customer.
  7. Install and configure the Data Agent (both on-premises and in the cloud).  The link included above will provide information on the installation and configuration of the Data Agent. You will also be guided to open required IP addresses and ports through your firewall to allow for communication from the Incorta Cloud to the Data Agent.  Reinforcing again, the Incorta Cloud will only communicate with the data agent to request data.  The Data Agent actually makes the connection to your data sources, gathers the data, and then packages it to send back to the Incorta Cloud.
  8. Once the Data Agent is operational, confirm and verify all data sources in the Incorta Data tab by using the "Test Connection" button and responding accordingly to resolve any connectivity issues.  Note: it will be necessary to get the JDBC connection string, ID and password for the cloud metadata DB, as this will have changed from your on-premises environment.
  9. Once all Data Sources are tested:
    • Either perform Full Loads for all Schemas; or
    • Perform Load from Staging for all Schemas if data was copied from the on-premises servers.  Any individual tables that may fail the staging load will have to be investigated, and then a Full Load performed for that table if the staging load will not complete.
  10. Once data is loaded, verify key dashboards to check if content is loading as expected.
  11. Security: Verify & Configure SSO is working and that LDAP synchronization is working.  Note: if you were running LDAP synchronization scripts previously from your on-premises servers, then you'll need to migrate them to the cloud and Cloud & Support teams can schedule them for you.  If your LDAP servers are not accessible from the public network, you will need to work with your Incorta Services team to remediate the sync process with you to come up with an alternative approach. 

Related Material

Best Practices Index
Best Practices

Just here to browse knowledge? This might help!

Contributors
Version history
Last update:
‎08-10-2022 08:24 AM
Updated by: