|< Day Day Up >|
With all the technical designs and migration plans in place, it is time to execute our migration. Following the project plan, we will minimize risk by using our tested processes and having our contingency plans at the ready. In the best of projects, this phase is anticlimactic because everything operates according to tested plans.
Building the New Environment
The first step in implementing our migration is building the new environment. This is a tedious job that involves manually paging through the /etc files on the old server and replicating the configuration on the new Solaris environment. Ideally, this will be done through JumpStart configurations; however, it can be done by hand. The important trick here is not to blindly copy files from the old environment to the new environment. Slight differences in syntax and meaning still exist between the two operating systems. In fact, scripting should be used as much as possible to enact the exact commands used in Solaris to create the configuration files. While this is not always possible, especially when we might not be able to obtain user account passwords to recreate the accounts, it is preferable in many cases.
Once the servers are configured, we will need to provision them with applications and data. Because only a few servers are being migrated , this is a straightforward process whereby we manually install applications on the servers. In larger migrations, we might choose to use JumpStart software to deploy applications and the OS to provide a standard, repeatable process. JumpStart should also be considered in complex migrations that might, for testing purposes, require several installations.
Data transfer is also relatively straightforward. All file-based data are copied by NFS from the old servers to the new servers. Database data is exported from the old platform database (with full schema) and reimported onto the new platform database. Database tuning and index creation are handled after this conversion.
Testing the New Environment
Testing for this example migration is not as difficult as it could be for many migrations. Because we have ported a minimum amount of source code and have kept much of our data intact, we will not have the testing complexity many migrations require. However, that does not excuse our team from following the appropriate testing best practices.
At a minimum, the following tests need to be performed:
Our team has performed a number of application upgrades over the years , so they have already created a number of test plans. These are reviewed and slightly modified for their new purpose by addition of some Solaris OS-specific tests.
Documenting the Migration Project
With the implementation phase of the project almost complete, we take some time to document our successes and failures. Because we have already planned several more migration projects, it is important to preserve what we have learned. To this set of best practices, we also add the project plan. This will give us a head start for planning the next migration project we undertake.
|< Day Day Up >|