Changing your toolset can be a headache at the best of times, but when you have multiple tools and potentially multiple platforms, handling large amounts of critical customer communications getting the migration right can become a juggling act of monumental proportions. Here are ten steps to take away some of the pain.
Migration of Document System Applications needs looking at from more than one angle. The principle, and often the only focus of a migration are the Technical Considerations. This will include obvious details such as set-up and install of software, requirements gathering, system design, development, resource management and output management. Often overlooked, but just as important are the business considerations. Failing to consider the overall business impact and people involved can endanger the success of your migration. Nobody can guarantee a pain free migration, but following the ten steps below will reduce your risk to a more manageable level
Step One: Analyse and Document
The first thing you need to look at is the documentation for the existing applications. Is it all up to date? Are the specifications for your existing templates, logic, data mappings, and archival and output requirements all complete and accurate? Without a complete and accurate idea of what the application does today, how will you know whether it does what it is supposed to when the migration is complete?
Step Two: Identify Future Requirements
Establish a high level view of already agreed and potential new requirements for the next 12 to 18 months. This doesn’t need to be at a detailed level, however you should involve at least the Project Board, Business Managers and IT Managers to get as complete a picture as possible. This will enable you to build future proofing into your system design.
Step Three: Understand the End Result
Make sure you have a detailed understanding of the Business Requirements. All too often the focus is on the technical requirements and this can lead to including outdated work-arounds. Gaining a detailed and up to date understanding of the business requirements will ensure you only replicate the required elements of the original system, and not the fudge’s and work-arounds that had to be included because of restrictions in the original software.
Step Four: How will it be developed?
Consider how you are going to develop the new application. Are you going to do it all using in house resource, which will require significant retraining of existing staff, are you going to use external resources with prior experience or a combination of in-house and external resource? Co-development has a lot of advantages. A collaborative effort retains the knowledge of your application within the team and bringing in experienced external resource can bring benefits such as best practice recommendations and rapidly developing confidence and skill levels in the new tool.
Step Five: It’s all about the data
The structure and format of the data can make a real difference to how straightforward or challenging your application will be to build. Take the time to make sure you get your data layouts right. Key factors include potential platform changes, are you moving from an EBCDIC platform to ASCII? What needs to be done to handle the translation? Will your new platform have access to all the same resources? This can be crucial if your old application used database look-ups. How are documents driven within your new software? Does it require a particular hierarchical structure, or particular format such as XML or CSV? Mistakes in the data layout can be expensive in terms of man hours to correct at a later stage so ensure you do everything possible to get it right first time.
Step Six: External Resources
How are your external resources handled? Do you need to convert any images or fonts to a different format in order to use them in your new software? For example, your previous application may have been producing AFP, and therefore may use AFP bitmap images. If your new application is going to produce pdf’s then you need to get your images into a PDF compatible format such as TIFF or JPEG. Are you able to source the images in the correct format or do you need to convert existing images?
Step Seven: Development Plan
Do you know the order in which the various elements of the application need to be put together? Make sure you are aware of any dependencies in the build order before you begin so you can plan use of your resources accordingly.
Step Eight: Output Handling
Make sure you identify all of your output handling requirements up front. Is there any unusual output handling that needs to be included, do you know how all of your streaming, archiving, sorting and batching is going to work?
Step Nine: Change Management
Spend time planning how you will handle and track change management with your new tool. Does it have any support for versioning of source code or will you have to develop your own procedures? How will the new application be implemented in the production environment? Are you geared up to provide out of hours support should it be required?
Step Ten: Business Issues
Moving to a new composition tool has implications beyond those of a technical nature. A new tool will have different source code handling methods. There are security implications and versioning issues to consider. How are you going to handle change management whilst the new application is being developed? Is it possible to implement a change freeze or will business drivers force you into duplication of effort? Will you have the resources available to handle dual platform development? Don’t forget the people factor. Moving from one platform to another can cause your team to feel de-skilled and de-motivated as they are forced out of their comfort zone. They can become a real risk to the project if not led effectively. Communication is vital at this stage, keep people informed of training plans and give them realistic achievable timescales to become confident in the new software.
… and finally
It can be very tempting to recreate your legacy application exactly as is on the new platform. Don’t! Remember there is a reason why you are migrating!