How long will the final migration take?
The migration process includes many steps, involving many different resources. First, data is extracted from your legacy system and moved to the SFTP that will transfer your records to us. Depending on the volume and complexity of your data, as well as the strength of the internet connection, this could take some time. Once the data is on the SFTP, Case IQ will copy it to the server for your new application, and then a script is run to migrate the mapped records to where they need to go. Again, depending how many records you have and how detailed each one is, this could take a while.
Typically we run migrations overnight so that they are ready for validation first thing in the morning. In general, it’s best to assume that it will take about a day for your team or your data vendor to extract your legacy data and move it to the SFTP. Moving the data from the SFTP to the server and running the script to consume it typically takes about a day and a half, and then you’ll want some time to validate the success of the migration before we consider the migration complete.
Planning ahead to ensure that all the proper resources are available at the right time will help ensure that your migration runs smoothly, but be prepared for an interruption to your case management for at least three days.
Can I schedule my final migration for a weekend?
If it’s necessary to avoid major disruption to your business, then yes, but there are risks associated with this. We recommend running a migration during the business week simply because it’s easier to guarantee the availability of resources when needed, both from your data team/vendor, your team, who will need to be on hand to validate the migration, and our own team. Scheduling a migration while businesses are typically closed tends to cause more complications than it solves.
What happens if something goes wrong?
We fix it! Sometimes there will be errors in the way that data has been mapped, or data migrated into the new system won’t appear exactly the way that it appeared in your legacy system. In these cases, we make an update to the migration script and run the components of the migration again that are needed. In extreme cases, it’s possible to begin again with a clean slate. Your original data extract still exists intact and can be re-copied and re-migrated once the issue has been resolved.
How do I validate the migration?
If there is an error with the migration, it will not be isolated to a single record; in other words, if you see the error on one record, it’s likely that the error exists elsewhere. We recommend taking a sample set of your data to validate, rather than reviewing every single record. Ideally, your sample set should include cases of each case type, and these should be at different workflow statuses (open versus closed). If you have access to your legacy system, it’s a good idea to compare the data there to the data in the new records to ensure that they match. If you don’t have a set of criteria for how to test your migration, your Implementation Lead will be able to offer you guidance.
How do I deal with cases that come in during the migration process?
This is ultimately up to you. If you are currently recording your cases manually into a spreadsheet or other document, then continuing to do so for the duration of the migration and then re-entering those cases into the new application should make little difference to your day-to-day business. Keep in mind that any edits your users make to legacy data after the extract has taken place will not be reflected in the new system.
If you experience a high volume of new cases daily, especially if you have an externally-facing portal that allows the public to submit queries and complaints, then this might be a more complex issue. You will need to restrict access to your legacy system after the extract has been taken. Many of our customers will display a banner on their public portal to explain the service interruption; others with only internal users will develop a change management plan to accommodate for new queries during a time when neither the legacy application nor the new application are available.
What happens to my legacy system when the migration is completed?
Your legacy system will remain active while we validate the migration, but any changes made to records in your legacy system will not be updated in your new Case IQ application; for this reason, we recommend either setting your legacy system to read-only (for Domino and v2 systems), or to disable access for all but a select few users (for v3+ systems) during the validation phase.
Unless your contract states otherwise, the legacy application will be turned off after implementation of the new application is complete. During the adoption phase of your new project, the Case IQ team will back up the legacy system one more time for permanent storage and shut down the server, rendering the old application inactive and inaccessible.
Will we be able to use the same reports we had in the old system?
Sadly, no. Not only has the structure of our platform changed over the years, but so has Yellowfin, and copying an old report from a legacy system to a new one is simply not possible due to the changes in the way that both applications are built. We offer standardized training in report building as part of the implementation process, and if it is in the scope of your contract, we can assist you in rebuilding some of your key reports.
What will happen to data I no longer need for reporting but want to keep for reference?
We can send you a copy of your legacy data in its entirety, via SFTP, for you to store and use as needed. Simply mention this to your Account Manager and your Implementation Lead.
