By Dave Howes, Systems Engineer
System migrations are a necessary part of moving your business to the newest technologies. If you are looking to move to a new IBM FileNet system, you will certainly need to understand this process.
Despite understanding the end result of a migration, many managers don’t know the actual process of a migration and what it entails. A deep understanding of the process will help in planning ahead for how long the migration is going to take and when. In addition, it will aid in understanding the high cost associated with performing a migration.
I’ve been working on FileNet migration projects for about a year now so I put together a list of frequently asked questions/important information that will hopefully help you better understand the migration process so you can effectively plan for it.
What is a FileNet migration?
Migration is the process of moving data from one system to another. This process may also require changing the format of data depending on if the data is stored on a different type of database, or being applied to a different application. During a migration, it is important to know why and how you will adapt your data for your new business solution.
Why is a FileNet system migration a big deal?
FileNet migration is a delicate and complicated process. When performing a migration, there are potentially millions of documents that need to have metadata and related data converted to a form that the new system can understand. Poor management or rushed migrations can lead to issues for years to come with either corrupted or missing data.
What does it entail?
A migration begins with extracting data from the old system.
You need to format the extracted data in a consistent and uniform way to prepare for the next step, which is conversion.
During conversion, the data will be reformatted to match the requirements of the FileNet system. This could include changing document formats and types to be compatible with the new system.
Once this is complete, the last step is for FileNet to ingest the data. Often, this will be your longest step, as your FileNet system will need to perform actions such as reassembling data relationships and applying security.
Who is involved in a migration project?
Typically, a migration team consists of several parties: the project manager, a QA team, migration vendor, IT and business analysts.
The QA team works closely with the migration vendor to ensure that what they migrate during testing is correct in the new system. The biggest challenge here is that there are a lot of factors to consider, such as document type, annotations, file systems and naming schemes, and that only accounts for a few. For a QA team to effectively deal with this, it is important to communicate with the migration vendor as much as possible to identify and test trouble areas.
Migration means your IT team will monitor and manage multiple databases and systems. A major concern for IT is ensuring that read and write permissions are correctly assigned at the correct times. For example, during the actual migration, you will need to set the source database to only have read permissions, otherwise, the data in FileNet will not match what is in the source database. To avoid problems here, coordination by a manager will be key
so that the entire migration team is in sync.
Business analysts handle the design of how to adapt and change data to fit in the new system. The main challenges for this group are ensuring that all possible types of data have mappings in the new system and that all data is uniform. If the migration vendor does not have all the mapping information or that information is not consistently formatted, the vendor will not be able to correctly migrate all the data. Have your business analysts work closely with the migration vendor to identify edge cases to avoid data loss during migration.
The migration vendor, or a point-person within your company, handles the data extraction, conversion and ingestion into the new system. Their most difficult task is communicating problems between the different teams. Often times, the migration vendor has to interact with the QA team to find a problem. Then after identifying where this issue is within the migration, relay the information to the business analysts to collaborate on a solution. This is why it is vital to have either a vendor or an individual experienced in migrations in this role.
What does migration mean to managers? To the IT/tech team?
When running a FileNet migration, managers should expect several months of planning followed by a few weeks of migrations depending on the size. As a manager, you should expect to first organize your business analysts to determine what information you need to migrate to the new system. This also includes determining which documents need an alternative file type, properties to rename, and file structures to change.
Managers should look to their migration team to extract, convert and ingest the data into the new system and to execute the changes laid out by the business analysts. During all of this, your IT team will prepare and manage databases as needed to ensure a smooth process.
Should I consult with a migration vendor?
A migration vendor can provide experience and an expedited process for your system migration. Vendors typically are already equipped with the tools to perform a migration which includes proprietary software that can handle the conversion and ingestion of data into the new system. Not only that, but vendors are experienced in extracting data from various systems. This leaves the organization to focus on prepping environments and designing how the data should look in the new system.
If you have an individual or group experienced in running a FileNet migration, then it is okay to handle the migration yourself.
Keep in mind that doing so involves some additional work, as you would not be able to take advantage of the proprietary software that migration vendors typically have to perform data conversions and then ingestions into FileNet.
How long does a project like this take?
It’s important to note that migration projects take time.
Planning a FileNet migration can take months of work, and even once that planning finishes, running the actual migration may take multiple weeks.
Migrations take place during non-business hours which usually means evenings or weekends for most organizations. It is important to keep this in mind when setting expectations for how long the project will take and for structuring your employees’ work weeks during the migration.
A general rule of thumb is to expect that in one weekend, you will migrate one million documents. This is definitely subject to fluctuation depending on how many workflows launch for each added case or document. Theoretically, you may be able to migrate more in a weekend, but our team generally aims to be done by Sunday morning so if it takes longer than expected or runs into problems, there’s enough time built into the schedule to avoid impacting your users.
An IBM FileNet migration doesn’t have to be daunting or dreadful. If you take the time to prepare and understand the project you’re about to embark on, then there will be fewer speed bumps along the way.
If you want to learn about the tool that my team regularly uses to ensure smooth migrations you can read more here.
About the Author: What I enjoy most about working at Pyramid Solutions is the ability to be proactive with your creativity, like creating your own project or writing a company blog! As far as free time is concerned, I’ve recently taken up game development in a dream to one day publish my own game. In addition, I have a deep love for fencing and board games.
