As my colleague Brian Finnerty pointed out in his recent blog, we’re continuing our webinar series on Managing Application Development Teams & Software Projects with a webcast entitled Legacy System Migration to .NET on 
Thursday April 14th 2:00 PM Eastern/11:00 AM Pacific. Our guests on this occasion are the global healthcare company, Cerner Corporation.
In hosting these webinars, our goal is to make common software management issues as real as possible and to offer thoughts and strategies that might be relevant to you in your work. We are also keen to share “war stories” that make the issues come alive. We’re extremely lucky to have Cerner’s Matt Anderson and Ryan McKenna joining us for this webinar. They were both deeply involved in the project to migrate a key product from a legacy system to the .NET framework and the challenges associated with that process.
When I do my own preparation for these webinars I like to find an angle that allows me to open the issues up. For this webinar, I discovered a Department of Defence white paper on Legacy System Migration Guidelines. Since DoD systems contain a substantial amount of legacy software and they have worked with many vendors to carry out migrations, they have evolved 10 guidelines which are built on lessons learned from actual legacy system migrations. On first reading, some of these guidelines are blindingly obvious. For example, guideline #1 recommends that you “Develop a comprehensive strategy with achievable and measurable milestones for each reengineering project”. Indeed 
— you don’t need to be a rocket scientist to agree with that one!
But some of the guidelines, when matched with the key approaches of the Cerner strategy, are really quite interesting and thought provoking. A couple of weeks ago, I spent a day with Cerner in Kansas City at their Innovation Center. We allocated one session to preparation for the webinar on Legacy System Migration to .NET. I was very struck during the meeting by the “Like-For-Like” strategy adopted by Cerner for the project. It’s not as simple as it sounds. Just think about it — you have a core product with many customers and users. It is a key revenue generator for the company. It has been developed over years. Now you need to move it to a new technology base. You decide on a “like-for-like” strategy, which means matching function for function, feature for feature. An ideal outcome would mean that users are not even aware of the change. But we all live and work in software. We know how products develop, how the outcome can change – sometimes in unexpected ways.
Then compare this decision with guidelines 4, 5 and 6 from the DoD white paper:
Guideline #4: Establish and maintain configuration management control of the legacy system
Guideline #5: There should be a carefully defined and documented process for the elicitation and validation of requirements
Guideline #6: Make software architecture a primary reengineering consideration
These three guidelines raise a ton of questions for me, which make the project, and decision-making around it, come alive. For example,
1. How are requirements for the new system documented?
2. Is the original architecture still valid under the new technology?
3. If not, what needs to change and what implications does it have for the project?
4. Does anything get dropped in the new system? What about the little funky features that wend their way into all products?
5. What about improvements and new features? Do they wait until the migration is done?
During the live webinar on April 14th, I will also ask our guest speakers about DoD guideline #3, which is near and dear to our hearts at InnerWorkings:
Guideline #3: If new technology is used for a project, provide adequate training in both the technical content and the motivation for change
The list of questions could go on – but the point is that these are real migration issues that Cerner grappled with, decided upon, and then executed against.
It is worth noting that Cerner’s migration project is complete now so we will also be able to talk about specific outcomes and lessons learned. The webcast will run for about 40 minutes and we will have a live Q&A after that where you can ask your own questions. So do join us. It promises to be a really interesting session.
