Change is not easy. For example, when a large scale migration is announced, quotes such as these will be heard around the office:

“This is a waste of time. Why change something that already works?”
“The project will be too expensive!”
“There is no one in the company trained on the new hardware! What will happen to us?”
 

There will inevitably be negative reactions by some when a migration project is announced, especially when it is a large-scale one that impacts a lot of people. Unfortunately, many good projects get bogged down or even canceled because these type of reactions were never considered.

Here are two suggestions to help mitigate the impact these reactions can have on a project. The first is to allow those who have concerns to address them early in the planning phase. Keep an open mind, since many of the concerns will be legitimate and should be considered in the migration plan. It is also important to realize that, unless there is a compelling reason not to continue after these initial concerns have been addressed, move on with the project.

The second suggestion is to establish and maintain a good communications link between everyone involved in the project. Regularly scheduled project updates, meetings and emails are ways to do this. Doing this dramtically reduces the possibility of misunderstandings, rumors, and of people feeling “out-of-the-loop” on project matters.  Despite doing everything right, the old rule, “you can’t please everyone,” still applies. If this is discouraging, remember the ultimate goal of any migration project is to improve the way a company conducts business. Focusing on this and the other advantages to be gained after go-live is the best incentive to seeing a project to completion, despite some of the negative reactions that will be encountered.  

Several years ago, my Internet provider began an ambitious upgrade of their network with promises of increased speed and reliability for their customers. However, instead of receiving what they promised, the connection was extremely slow and sporadic. After a couple of days and several phone calls to their customer support, I asked the support manager if they were intending to return to their original configuration until the problems they were having could be resolved. I was shocked when he explained that they did not have a fall back plan and could not go back. Two weeks later, the connection was finally stable enough to use. Unfortunately for the provider, they lost a substantial amount of revenue after issuing refunds to those affected by their upgrade. They also suffered a great deal of embarrassment and loss of goodwill with their customers.

A situation like the one my provider faced could have been avoided if they included a fall-back plan in case a problem like the one they faced comes up. Such a plan always needs to be included in case a situation arises during the migration which cannot be readily solved in a reasonable timeframe.  The plan can be as simple as removing the newly installed application files or as complex as restoring the entire system to its original state using a full backup taken before the upgrade.  Regardless of the complexity, the fall-back plan needs to be in writing and include the list of steps needed to recover the system to its original state. The plan also needs to describe at what point in the upgrade and by whose decision the system needs to be restored to its original configuration.  This helps to reduce the tendency so many of us have to continue pushing forward with the possibility of complicating an already serious situation.

Once the plan is written and if time and resources are available, it should be tested. Finally, it needs to be communicated to everyone involved in the project, especially the users.  This reassures them that you are prepared and avoids any surprised reactions in case a problem does occur.

Making the transition from one platform to another poses numerous challenges. Over their life-span, application environments have been specifically built and tuned to take advantage of their host’s operating system’s unique features and customized to meet a company’s specific needs. These environments often make extensive use of software that is proprietary and designed specifically for the host’s operating system.The new platform usually offers a very different environment and as such the original application environment must undergo a number of modifications before it can continue to work on the new platform.  Some of the technologies used, such as COBOL, are very common, but every company’s application environment is unique and includes technologies that are used in different ways. 

As a result, there is no one-size-fits-all solution to the challenges of a transition. For some companies, these challenges can be significant and can represent serious effort and high cost. TRANSITION APPROACHES
A system transition involves a combination of approaches. Once a system inventory has been performed, each major component of the system needs to be considered individually and as part of the whole. What should happen to the component during the transition? Should the component be migrated, replaced, re-engineered or abandoned? These approaches are discussed below:
            • Migrating components: Also sometimes referred to as “re-hosting”, migration entails transferring the component’s main code and functionality to the target platform. This approach usually entails keeping the same language or code base or, in some cases, converting to another language while maintaining the same functionality. Migration almost always entails some amount of code adaptation.
            • Replacing components: Replacement entails replacing a major portion of code or the entire code set with another technology, a packaged application or software. This approach normally requires some effort to adapt the old environment to the new one.
            • Using libraries, OS mapping or emulation to maintain components: These activities involve using technology that maintains many original OS concepts, commands and intrinsics on the target platform so that the complexity of the transition is reduced.
            • Re-engineering components: Re-engineering entails performing a significant amount of code modification to adapt to native target platform functionality, to new requirements or to the new platform’s environment. For example, re-engineering may be required to find native equivalents for the original database, commands and intrinsics.
            • Retiring components: You may sometimes decide not to bring forward a component or its functionality to the new environment. Some degree of effort may still be required to make sure there is no impact to the surrounding environment when the component is retired.From my experience, a total system transition involves a combination of such approaches depending on the system component.  Which approach is best, depends on a number of factors.

This text was meant to give a very simple overview of some of the common challenges related to a system transition.  I know I didn’t invent anything by writing this, but I hope that this summary will serve as a foundation for future migration-related entries.

Nick Fortin
SIG Migrate Chair
Product Marketing Manager - Speedware

I wanted to share some information which is not talked about very much and which may be useful to the readers who own an HP e3000 server and are interested in the subject of HP e3000 transitions.  Although the basis of this article is for the HP e3000, this information can most probably also relate to other platforms and database types.

For some companies, one of the most critical topics to focus on during a migration planning is the deployment strategy and its impact and relation to data migration and data cut-over for moving to production.  More specifically, the use of a data synchronization technology sometimes required to support the desired deployment strategy.

A database synchronization technology facilitates the synchronization of data from one database type to another, usually located on different platforms (making sure updates performed on one database are also performed on another database; keeping the two synchronized).  A basic example of how this would apply for say, Image to Eloquence, would be to migrate an Image database to Eloquence and then keep the Eloquence database synchronized (updated) with the transactions performed on the HP e3000.   Why would you want to do this?  Well, I have some examples below.

So let me go over some migration challenges or caveats related to this topic.  You may need a data synchronization technology if one of the following applies to you:

         A) Your databases are large and your available downtime small making it impossible to migrate all your databases at once in the final cut-over period (this is sometimes referred to as the big-bang approach).  To explain, first let’s make some assumptions…  We’ll assume that the databases are large enough to require a significant amount of time to migrate from one type to another.  In addition, we’ll assume that an organization has a small downtime period allowed for switching the users to the new system.   These two traits combined pose a data migration challenge because at the moment of final data cut-over before moving all users to production on the target system, the time needed to migrate the Image databases surpasses the time limitations for the HP e3000 system databases to be un-accessed (ie: database downtime).  These two criteria show potential synchronization need.  In this scenario, once a snapshot of your databases is taken (using a backup, copy or an export of your databases) during the transition project, you could use a synchronization tool to keep your target database synchronized with updates continued to be performed on the HP e3000.  This scenario represents unidirectional synchronization from source to target.
         B) Your testing strategy requires platform parallel testing of screens and reports (and sometimes transactional programs) based on production data whose results depend on the exact same data values from both source and target databases at any given time. This scenario represents unidirectional synchronization from source to target.
         C) You envision a contingency backup plan to revert back to the HP e3000 after having moved into production on your target server (for a set period of time like a week or two), in the event the migrated application environment has some serious problems.   You would then need a synchronization technology to keep the Image databases synchronized with the target transactions.  This scenario represents unidirectional synchronization from target to source.
         D) You envision a deployment strategy which requires a phased deployment of portions of your application(s) into separate bundles migrated, tested and moved into production.  In this scenario, you have the same databases (usually some of your databases) on your source and target system accessed/updated simultaneously live in production requiring that databases on both platforms be kept synchronized with minimal discrepancy delay.  Due to the importance of having data integrity between databases on different platforms, this scenario also usually implies using a 2 phase-commit mechanism to ensure data is posted correctly before the application process can move on.  This scenario represents bidirectional synchronization from source to target and target to source simultaneously.

There are a few synchronization technologies available which support a number of database types including TurboImage, each of them carrying their own strengths and “particularities”. 

Another branch of this topic is data synchronization for flat or ksam files.  Although flat files are usually small in nature, a company that has hundreds or thousands of flat files to migrate can be faced with the same challenges noted above for databases.  As the migration process, challenges and solutions for files are different than it is for databases, file synchronization is out of the scope of this article. 

In summary, synchronization can:

·         Help with a phased deployment for the data cut-over
·         Help with 24X7 or extreme uptime server requirements
·         Help to run HP e3000 and Unix systems in parallel in production
·         Help for a contingency plan in case the deployment is problematic

The previous information just scratches the surface of this topic.  If you want to find out more about data synchronization and how it would relate to your environment and particular needs, you should talk to an expert that has this knowledge.