Taking an enterprise out of the closed-source software deadlock into the less costly and more flexible world of open source software (OSS) is heady stuff. This series on migrating an enterprise to OSS is designed to help your project team keeps its collective head together during the process.

Download this free guide

Download: 14 Must Know Linux Commands

Discover the top 14 must-know Linux commands for server administrators, with 2 bonus articles giving in-depth knowledge on the benefits of the “IP” and “Mount” commands.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

So, in part one, we got our assets straightened out in a comprehensive inventory of the server room. Now, it's time to make a list of which products we need to install, the order for replacing old products, what we already have available and what other tasks to perform.

This list is your starting point, and it should be supplemented with diagrams, topology overviews and other charts.

Of course, this isn't an exhaustive list of OSS products you could use as replacements for commercial ones. There are many options.

Unfortunately, you may encounter proprietary systems or services that cannot be replaced with OSS products. Financial applications that require Microsoft's Internet Information Services (IIS) or a back end that needs Windows Server with the .NET framework are good examples.

Potential pitfalls and complications

In my opinion, a worst-case scenario list is a must for any migration plan. Make a list of all factors that could possibly interfere with a smooth migration. This is no time for denial!

In making your worst-case scenario list, don't focus only on products and systems. People problems derail projects more often that product problems, from my experience. Here are just a few contingencies that your team should consider:

What if certain members of your IT staff are forced to go on sick leave halfway during a critical phase of the process?

Do all key roles in the process have at least one backup person who is aware of the current state of events at all times?

If the project depends on third parties for contract work or support, will there be a holiday period during which these companies close?

Are there any unspoken or unaddressed concerns within your project team? Staff members who feel uncomfortable about the way things are being planned or controlled may find it difficult at a later stage to deal with the pressure of this critical operation.

Each step of the process should have a proper back-out scenario. If the newly installed service does not work properly upon deployment, a rollback to the old situation must be an option, so that business can continue while the problem is being solved.

Testing and pilot projects

A test environment is essential. Testing should be fully planned and must be conducted before the first OSS component is rolled out into the production environment.

Plan your tests in an early stage of the operation. This will give you enough time to consider the matter properly and to deal with complications when they arise. It pays to conduct a test migration one or two weeks before the actual migration.

Test environments may be small scale, as long as the planned systems can be give sufficient performance under a production load. Be it large or small, however, the test environment must implement all services, so that their correct functioning and interoperability can be assessed.

A successful test should be followed by a pilot project, in which a small number of end users from all affected parts of the organization work with the new systems in a production situation. The pilot presents a good opportunity to assess the effectiveness of user training and awareness programs. If users feel uncomfortable with the new environment, they may need further briefing before being exposed to the new work environment.

The pilot should start when all IT staff members agree that the new services offered are ready, and should continue until the end users agree that they're ready.

Roll-out

Replacing the old IT infrastructure with a new one is typically not done overnight. Most organizations prefer to implement components one by one, as far as possible. A rollout per department or location -- if multiple locations are involved -- may be preferable as well.

For some services the changeover may be relatively simple. For example, when a file server has been properly configured, it may indeed replace the old system overnight and the end users may not even be aware of the change. In other cases, a "shadow" configuration may be desired, where a critical service is rolled out while the old one remains live, and users are gradually moved from the old to the new system. Then, only when everything works perfectly, and everyone uses the new system, the old system can be decommissioned.

If large amounts of data are to be migrated from a live system, it may be possible to configure the new system to mirror the old one. Once replication is complete, a simple change in DNS records may be enough to make the actual changeover to the new system. Or, it might be possible to remap server volumes from the old to the new service.

The actual changeover is the moment that will have the greatest impact on end users. Once again, make sure that user training has been completed and that sufficient helpdesk staff is on hand to deal with peaks in support calls.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy