(This page uses style sheets.)
Much of what needs to be done to migrate from a proprietary environment to OSS is the same for any migration – for example from Windows NT to Windows 2000. Even in such single-vendor moves it cannot be assumed that file formats, for instance, will be portable, and suitable testing will be needed before any widespread change is made. All migrations must be based on careful planning.
These guidelines are not intended to be a manual on project management and the Administration is assumed to have sufficient skills to be able to manage the migration properly. The description below is intended to highlight the points that are salient to a migration to OSS.
The migration process should ideally consist of the following parts. Some of them can be done in parallel such as 2, 3 and 4.
Note that the information found may indicate that modifications will be required to the current environment before a migration to OSS can be conceived. This is why even administrations that have no immediate plans for migration, but which wish to keep this option available to them, are recommended to require only open multi-vendor standards and to assess their infrastructure against this (see also Chapter 7.3 below "Think Ahead").
Create a team with appropriate skills and management backing. It is important that there is management support otherwise there will be resistance to a move away from the norm of proprietary systems. This support will need to be sufficient to allow at least the building of representative pilots, so a basic business case will need to be produced with perhaps a more detailed one later on when more data is available.
Understand the target environment, both OSS software and the base architecture (see Chapter 8), together the various options and choices available. This means training existing staff, recruiting, or using consultants. This will require some initial cost and so requires sufficient management support. There is sometimes an expectation that software which is free can be understood and used without cost. This is not the case.
The migration is an opportunity to review the base architecture as well as the application software. The architecture recommended in Chapter 8 is one based on centralised control and has a number of advantages discussed in Chapter 8. There may be cost implications in making this change which need to taken into account.
It is very important that OSS is understood. There are a number of issues which need to be fully considered before making any decisions.
The implications of OSS licences need to be clarified particularly if the Administration could be deemed to be distributing any changes to software. See the documents referred to in The Introduction for details.
Where there are several choices for any one function – for instance there are at least three good quality OSS spreadsheets available – Administrators need to understand the pros and cons of each product.
The differences between the various distributions must be considered. Some distributions are backed by commercial companies who provide support and fixes. Some have distinct characteristics, for instance Gentoo provides a distribution based on source code allowing the Administration to more easily customise the software to cater for their own specific needs. All these differences need to be assessed before a choice is made.
Administrators must determine what level of support is required. Commercial support can be obtained from the developers of the application or distribution if they provide it. If not, third parties can provide support because the source code is available and there are many companies providing such support.
This is a distinct difference from the proprietary software market where detailed support can only be provided by those companies who have the privilege of access to the source. This becomes important if the proprietary vendor goes out of business without releasing the source code.
If all else fails most applications have active mailing lists where a question or plea for help will be answered by someone with an interest in the application. The presence of an active mailing list and user community is often one of the criteria in the selection of software components in the first place.
Audit the existing systems. This data will not only be needed to do the migration itself but much of it will also be needed to construct a cost of ownership model for a detailed business case. Compile inventories of:
For each application used:
The application name, version number and contact point to answer enquiries.
How many users require access to it.
What operating system is being used. What operating systems the application can be run under, including environments such as Citrix.
What other applications are required on both client and server for the application to work.
What hardware is required. In particular does it require any non-standard or cutting edge hardware.
What protocols it uses to communicate with other applications.
What file formats it requires.
What internationalisation and localisation is required. Multiple languages and currencies may be required.
Data requirements. This should be interpreted in the wide sense which includes, for instance, word processing documents and spreadsheets, sound/voice data and visual data as well as the regular databases. In general, anything which is intended to be processed by a computer.
What are the constraints on interfacing with systems or users outside the control of the Administration?
What requirements are there to keep data and be able to process it in future? Is there a repository of existing legacy data which has to be supported? If so, does it require specific applications to process it?
Divide the data into the following categories:
Data which is not necessary to keep and can be thrown away. Throw it away.
Data which must be kept and is currently in an open format such as PDF or Postscript, or can be easily translated into one. The cost of translation needs to be assessed.
Data which must be kept but which is in a proprietary closed format which cannot be easily translated into an open one. This data may need copies of the specific proprietary application to be kept. The cost of these applications will need to be assessed. The required number of copies of the application can be determined by the degree of access to the data that is needed. For instance, if the data is only rarely accessed then a single copy on a central machine may be sufficient. It may also be necessary to maintain specific hardware to run these applications.
Security requirements.
What is the current system for assigning user names and passwords? Do user names have a structure and if so what is it? What is the policy for password updates?
Are there any systems requiring authentication other than a simple user name and password challenge?
What Administrative and Government policies are there relating to the use of computers? For instance, are there restrictions on the use of the Internet and email?
Are there security arrangements which require the use of specific hardware or software?
Make a detailed business case for migration. This will be based on the data gathered above and will consist of a number of sections including:
The cost of the existing environment over a reasonable length of time such as 5 years with assumptions appropriate to the Administration.
The cost of alternative environments and the cost of migration to each over the same period.
The strengths and weaknesses of the current environment and the various alternatives.
The associated spreadsheet will help to do the cost comparison.
Consult with the users. Explain the reasoning behind the migration and the effects it will have on them. Take their concerns seriously and allow them to play with the technology as soon as possible. The sooner the users become involved the better. This may be a legal requirement in some countries but should be done in any case to ease the introduction of what may be a significant change to working practices.
Create a help desk which can answer user concerns. Later when the migration is underlay it can answer problems and become a centre of excellence and good practice. Create an internal intranet site with a “tips and how-to” section, which can be updated by users themselves. It is important that the users feel included and the site will also give the help desk an idea of the sort of problems being faced by users.
Assuming the business case has been made, start with small scale pilot projects, preferably in a self contained environment with a small number of users. This will provide, among other things:
Data for more refined Cost of Ownership models.
User reaction which can be used to ease the introduction of other systems.
Validation or modification of the target architecture and the business case.
Decide on the speed of the migration process once it gets started. The main options are:
Big bang: All users change from the old system to the new one on the same day. In practice this is likely to mean scheduling the change over a weekend or national holiday. The advantage is that no dual-access provisions are needed and staff do not find themselves swapping backwards and forwards between systems. Disadvantages include the high risk and the very large resource requirements during the changeover. This migration scheme is only likely to appeal to small Administrations.
In any case if at all possible AVOID BIG BANG MIGRATION. Big bang migrations will have so many variables to control that they almost always fail. If they do so it is unlikely to be because of a failure of OSS but of management.
Phased transition in groups: Users are moved from the old system to the new one in groups. It is likely that complete functional groups would be moved together, to minimise data-sharing and group working problems. Risks can be contained and resources managed by choosing appropriate group sizes. It may be possible to do a rolling hardware replacement of desktop PCs at the same time, upgrading the machines removed from one group and then installing them in place of the next group's old machines.
User by user transition: Essentially the same as the group transition option but with a group size of one person. This drip-feed method has a low resource requirement, but is inefficient and unlikely to appeal to large Administrations. It may be an appropriate way to run the pilot projects though.
It is likely that old and new systems will have to run side-by-side for some time. It is important to have a transition strategy enabling old and new systems to work together, so that production activities can proceed adequately during the transition period. The replacement of the last machine may take a very long time (or never happen), so coexistence is likely to be very important.
Roll out the migration to the whole Administration. This will involve further training of users and technical staff.
Monitor user feedback and fix any problems which arise. Some user requirements may be sufficiently obscure that they cannot be predicted in advance or discovered during pilot projects. Ensure that sufficient resources are available to deal with such requirements after the transition.
At any time it might be found that migration is not feasible. This could be for instance because there are critical applications which will not work satisfactorily under an OSS environment and the cost to rewrite them is too high.