Preparing for a Legacy System Migration
By Clayton Williams
You have decided to migrate or extend an existing system or application and you are wondering what the next step should be. The first thing you need to assess for yourself and your organization is what type of migration are you interested in?
1. Straight Migration
This means you want to move an existing system to a different technology altogether without any feature upgrades. This is mainly done if you are only interested in reducing maintenance costs and improving performance.
2. Extension
This means you want to add an external application interface that accesses and updates the same data that the current system accesses. This is usually done because the current system is running fine, but it is not cost effective or there are no options to upgrade the current system.
3. Migration with Upgrade
This means you want to migrate all the features, security, and data of the current system, but add some new features and review existing ones. This is usually because the scope of the original system has changed significantly or an organization feels it is cost effective to review and include upgrades during the migration instead of in the future.
What is my system about?
Before you think about what features are going to be migrating you should take a step back and review your current system. Often times companies will move forward without fully understanding the scope and complexity of the current system. Here are a few questions you should ask when reviewing your current system:
1. Who is my audience?
Understanding the stake holders of a system is essential. This means you are looking at who touches the system. Many times, who was once the intended audience is not who it is suppose to be.
2. What are the roles?
Now that you know your audience can you define what role each one of them performs in interacting with the system? If a supervisor or administer uses the system, what do they do and what are the security restrictions that govern that role?
3. Who shouldn’t be using the system?
Security is an often overlooked concept when it comes to applications. Having an idea of who shouldn’t be accessing the system allows for a better understanding of how security will play a role in the new system.
4. What is the scale?
Scale is usually determined by two factors; the amount of data or records that are managed and how many people are accessing the system at any given time.
5. What are the inputs and outputs?
This is the most important concept in reviewing your system as it directly relates to the features the new system must replicate. The recommended approach is after you look at your audience and the roles each of them play, for each role. What data do they enter and update? What data can they pull from the system? These are usually defined as Forms (Inputs) and Reports (Outputs).
Sample:
System Administrator Role
Inputs
- Add / Edit / Delete Users
- Name
- Phone
- Department
- Email
- Role
Outputs
- Run a usage report for the past seven days
- Name
- Last Login
- Time Spent
What are the issues or needs?
Now that you have a thorough understanding of your system you can take a look at what the issues are. This is focused on why you want to migrate. At this point it helps to categorize the issues. This may also change your perspective on what type of migration you need versus want.
1. Performance
Are there any pages or screens that are no longer needed, confusing, or can be consolidated? Do certain features perform unreasonably slow?
2. Features
Are there any inputs or data you want the system to handle differently? Are there any additional inputs or data that the system should be managing? Are there any inputs that manage data incorrectly? Are there any outputs that display data incorrectly?
3. Security
Are all the current security restrictions and parameters correct or do they need to be modified?
4. Other
Are there any additional issues that need further review?
What do I need to consider?
There are several areas that can cause complications before, during, and after a migration. The following is a list of considerations and concepts you should understand before moving forward.
1. Availability
This is the ability of the system to be running and available to all stake holders. When migrating a system it must be clear as to how the switch from the old system to the new system is going to take place and what precautions are being used to ensure adequate availability.
2. Communication
The success of a migration is largely determined by how well the developers can communicate and have access with stakeholders or management. This ensures that questions and testing proceed in an efficient manner. It is also helpful to ensure that there are scheduled times to meet and discuss the progress of a migration and any issues that have surfaced.
3. Road Map
When a system is reviewed for migration there should be a road map that outlines everything the system should do and how people interact with it. Priorities should be clear and authorized personnel should be noted. If this is not clearly written it means that deadlines may be pushed back and possible loss of features or concepts may result.
4. Priorities
Often times there are features or concepts of a system that have a level of priority. These priorities should be listed in the road map. This will help determine if a feature is really needed and if additional considerations should be made for higher priority items.
5. Expectations
Often times when migrating a system, there are concepts or features that don’t translate exactly as they did before. It is recommended that your focus be placed on what is being accomplished and how efficiently is it accomplished instead of how the concept or feature was before. Good communication during a migration allows you as the owner or manager to understand these issues and make an appropriate decision moving forward.
6. Permission
Significant setbacks can occur if there is confusion on who has the authority to say what goes and what doesn’t when issues arise. This can usually be avoided if a well thought out road map is constructed before implementation begins.
7. Testing
There is usually a significant amount of time invested in testing a system by the developers during implementation. However, it is ultimately the requester’s responsibility to give it a thorough review as they have the best relationship and understanding of the data and processes the system manages. Doing so in a timely fashion before and after deployment will help to resolve any bugs.
What’s my solution?
There are several possibilities available out there, but the best solution is usually determined by the needs of the system. Once you have answered some of the basic questions described above you can approach a development team and ask what a good solution would be.
If you choose to go with i2Integration here is what you can expect:
1. i2Integration will meet with you and perform an initial review of your current system and discuss your vision for the migration.
2. Afterwards we would create a quote based on the information presented which includes an itemized list of the work to be done and a timeline for completion. This Quote is the road map for success.
3. Once approved i2Integration will begin migrating the system meeting with you throughout the project at scheduled times and contacting you when questions arise.
4. Testing and deployment are completed at the end and any problems are handled within a 60 day period after deployment.
5. We also offer options for continued support as needed.
Preparing for a Legacy System Migration
By Clayton Williams
You have decided to migrate or extend an existing system or application and you are wondering what the next step should be. The first thing you need to assess for yourself and your organization is what type of migration are you interested in?
1. Straight Migration
This means you want to move an existing system to a different technology altogether without any feature upgrades. This is mainly done if you are only interested in reducing maintenance costs and improving performance.
2. Extension
This means you want to add an external application interface that accesses and updates the same data that the current system accesses. This is usually done because the current system is running fine, but it is not cost effective or there are no options to upgrade the current system.
3. Migration with Upgrade
This means you want to migrate all the features, security, and data of the current system, but add some new features and review existing ones. This is usually because the scope of the original system has changed significantly or an organization feels it is cost effective to review and include upgrades during the migration instead of in the future.
What is my system about?
Before you think about what features are going to be migrating you should take a step back and review your current system. Often times companies will move forward without fully understanding the scope and complexity of the current system. Here are a few questions you should ask when reviewing your current system:
1. Who is my audience?
Understanding the stake holders of a system is essential. This means you are looking at who touches the system. Many times, who was once the intended audience is not who it is suppose to be.
2. What are the roles?
Now that you know your audience can you define what role each one of them performs in interacting with the system? If a supervisor or administer uses the system, what do they do and what are the security restrictions that govern that role?
3. Who shouldn’t be using the system?
Security is an often overlooked concept when it comes to applications. Having an idea of who shouldn’t be accessing the system allows for a better understanding of how security will play a role in the new system.
4. What is the scale?
Scale is usually determined by two factors; the amount of data or records that are managed and how many people are accessing the system at any given time.
5. What are the inputs and outputs?
This is the most important concept in reviewing your system as it directly relates to the features the new system must replicate. The recommended approach is after you look at your audience and the roles each of them play, for each role. What data do they enter and update? What data can they pull from the system? These are usually defined as Forms (Inputs) and Reports (Outputs).
Sample:
System Administrator Role
Inputs
- Add / Edit / Delete Users
- Name
- Phone
- Department
- Email
- Role
Outputs
- Run a usage report for the past seven days
- Name
- Last Login
- Time Spent
What are the issues or needs?
Now that you have a thorough understanding of your system you can take a look at what the issues are. This is focused on why you want to migrate. At this point it helps to categorize the issues. This may also change your perspective on what type of migration you need versus want.
1. Performance
Are there any pages or screens that are no longer needed, confusing, or can be consolidated? Do certain features perform unreasonably slow?
2. Features
Are there any inputs or data you want the system to handle differently? Are there any additional inputs or data that the system should be managing? Are there any inputs that manage data incorrectly? Are there any outputs that display data incorrectly?
3. Security
Are all the current security restrictions and parameters correct or do they need to be modified?
4. Other
Are there any additional issues that need further review?
What do I need to consider?
There are several areas that can cause complications before, during, and after a migration. The following is a list of considerations and concepts you should understand before moving forward.
1. Availability
This is the ability of the system to be running and available to all stake holders. When migrating a system it must be clear as to how the switch from the old system to the new system is going to take place and what precautions are being used to ensure adequate availability.
2. Communication
The success of a migration is largely determined by how well the developers can communicate and have access with stakeholders or management. This ensures that questions and testing proceed in an efficient manner. It is also helpful to ensure that there are scheduled times to meet and discuss the progress of a migration and any issues that have surfaced.
3. Road Map
When a system is reviewed for migration there should be a road map that outlines everything the system should do and how people interact with it. Priorities should be clear and authorized personnel should be noted. If this is not clearly written it means that deadlines may be pushed back and possible loss of features or concepts may result.
4. Priorities
Often times there are features or concepts of a system that have a level of priority. These priorities should be listed in the road map. This will help determine if a feature is really needed and if additional considerations should be made for higher priority items.
5. Expectations
Often times when migrating a system, there are concepts or features that don’t translate exactly as they did before. It is recommended that your focus be placed on what is being accomplished and how efficiently is it accomplished instead of how the concept or feature was before. Good communication during a migration allows you as the owner or manager to understand these issues and make an appropriate decision moving forward.
6. Permission
Significant setbacks can occur if there is confusion on who has the authority to say what goes and what doesn’t when issues arise. This can usually be avoided if a well thought out road map is constructed before implementation begins.
7. Testing
There is usually a significant amount of time invested in testing a system by the developers during implementation. However, it is ultimately the requester’s responsibility to give it a thorough review as they have the best relationship and understanding of the data and processes the system manages. Doing so in a timely fashion before and after deployment will help to resolve any bugs.
What’s my solution?
There are several possibilities available out there, but the best solution is usually determined by the needs of the system. Once you have answered some of the basic questions described above you can approach a development team and ask what a good solution would be.
If you choose to go with i2Integration here is what you can expect:
1. i2Integration will meet with you and perform an initial review of your current system and discuss your vision for the migration.
2. Afterwards we would create a quote based on the information presented which includes an itemized list of the work to be done and a timeline for completion. This Quote is the road map for success.
3. Once approved i2Integration will begin migrating the system meeting with you throughout the project at scheduled times and contacting you when questions arise.
4. Testing and deployment are completed at the end and any problems are handled within a 60 day period after deployment.
5. We also offer options for continued support as needed.