Sunday, October 05, 2008

What kind of variables do we need to study before writing down a migration project?

Before writing down a migration project for any organization, bussiness or public administration, it is critical to develop a methodology that ensures you have all the information needed to be able to design the correct procedure to switch PCs, users and network services from proprietary to software libre. To be able to design that methodology, one of the previous things you need to identify is which data you need to know from the pre-migration picture, how to collect it without having impact in the production process and how do you process it to be able to properly analyze it.

From my point of view these are the major variables (related with the workstation side, not the server side) that must be known. Most of them are obvious.



  • The organization that is going to migrate don't know the hardware they have.

  • Migration is about machines.

We need to know the hardware of the PCs because of, at least, these major reasons:

  • To determine if it is Linux compatible.

  • If it is, which driver or module should be included in the Linux system to install (also which kernel).

  • To determine if we have to install proprietary drivers. This have many legal implications.

  • To determine the optimal parameters related with the monitor and the graphic card.

  • To predict the most obvious performance limitations.

  • To determine the peripheral drivers needed.

System and programs installed


  • Nobody knows what is installed at 100%. You will have to find it out.

  • Migration is not just about machines. It's also about applications installed

We need to know, at least, this information related with the software installed:

  • The operative system, version and service pack. Probably we won't be able to migrate every app, so virtualization will be proposed.

  • Applications installed and its version.

  • Plug-ins, virtual machines (like Java) and other "not .exe" programs.

  • Links to local and remote programs, specially those placed on the desktop. Users will want those in the new Linux system.

Everyday used apps

Axiom: migration is not just about machines and application installed but also about programs really used.

The fact that a user have many programs installed, doesn't mean he/she use them all. The determination of the applications that are really important for the user in his everyday work is required. The interactions (related with apps and data) with other users from the same or different departments, with customers or other companies, will give you clues to determine the migration procedures and the tools needed.

Most of the times, users only use a few apps frequently. If these frequently used apps are shared by some users, the risk increases. You need to know who introduces data in those apps, who stress them the most, who use them for just consulting data, who will use them in the future, if there are plans to change it... It's critical to find a good solution for those. So, the more you know about them, a better picture you'll get.

Data and archives

Axiom: data is as important as applications and machines

The data that must be investigated is, at least:

  • Data related with their work.

  • Personal data.

  • Data related with special programs like browsers or e-mail clients, etc.

  • Configuration data, for example, the e-mail client configuration information.

  • Where is the data stored.


Axiom: users are as important as data and apps in a migration process.

Users are an important part of the migration. Maybe the most difficult one to analyze and satisfy.


In any group, there are people that leads the rest in every single area. It is needed to determine which users are leaders when you talk about computers. Relations between users within a group should remain the same after the migration process. Changing the hierarchy after the migration means adding a new problem.

To maintain those relations, you have to identify and study those leaders and their relations with the rest of the employees. They will demand more attention from the migration team. If they collaborate, you will have a lot of help when problems begin to show up. If not, they can become your biggest problem.

Knowledge and skills

It is important to find out which users have a better understanding of the Windows system, who knows about linux or, at least, if there is anybody that uses (or know something about) software libre apps under Windows. It is easier now than before to find people that knows what software libre or GNU/linux are. Some uses a Mac or a linux distro at home. For those people, switching to linux is going to be easier. Detect them.

Another interesting variable to know about is the skill users have using computers. There are people that knows a lot about Windows. Those will have a greater resistance since getting the same skills unsing Linux will take them time and a lot of effort. In one second they will go from being independent to not knowing anything about the operative system they will be using. In order to define the education proccess they will have to go through, you need to know the actual picture.

Complains and suggestions

How many people uses gmail at work because their corporative e-mail sucks?

Listen to what every worker has to say about the tools and services they use. Ask them about their wishes. Every single worker has a little clue to make the company more efficient. Be aware of their demands to reduce their resistance to switch to software libre. Tell them the truth. No not increase artificially their expectations about the new system and tools.


Axiom: migration is not just about machines, applications, data and users. It's also about interactions among these four variables. They are not independent.

The administrative structure of an organization sometimes is not exactly ported to the data, services or applications structure. Workers usually end up finding their way to do their job, overpassing imposed restrictions or corporative rules. They get paid for finishing their job, not for changing the rules. Many times is the technical team that allow them (or even help them) to brake some technical corporative rules, since they understand workers' point of view much better than corporative procedures or general politics.

How many executives use different tools and services than the rest of the workers? Sometimes this happens because of a good reason. But it is usual to see organizations that have people in command that do not give the technical department the credit they deserve, so they do not follow their advices. They do not respect the corporative rules either.

These special cases complicates the migration process since general procedures, politics (or even apps), are not followed by all the organization. It is necessary to understand what's going on (the workers vision) in every department in order to be successful. If you write down the migration project based exclusively on what technicians and directors tells will probably fail.

Companies are not isolated. They interact with other companies and customers. Those relation must be analyzed, specially if software is involved. IT providers are specially sensible to any change. You need to count on them in order to determine the migration process. This can be a tough problem if those providers work with proprietary software and do not follow open standards. There is no unique solution for these cases.

Since no lost of production is desirable, the migration process is determined by variables like schedules of the organization, bussines high or low season, employees rotation, etc. You must take care of those also. You won't migrate a toy store during Christmas, right?

The final picture

You need to know what should be final picture from everybody's point of view. This is important not just to determine where is the final point, but because an evaluation must be done after the process is finished. A lot of parameters must be analyzed in order to make a fair evaluation. Costs, resources and time are important variables to follow, but not the only ones.


One of the obvious things I've learned during the last few years is that a migration process is not just a technical process. This is easy to say but hard to understand. The first impulse is to throw yourself in a technical spiral of solutions, trying to define the requirements as fast as possible, to find out the best product, install it, configure it and teaching users how to use it. On the server side, you can make mistakes and turn back to the original situation without being killed (at least sometimes). But on the PC ...

The following risks have to be taken in consideration before writing down the migration project:

  • The loss of data.

  • The loss of functionality.

  • The reduction of performance of the new system.

  • The lost of interaction capabilities (with other users or services). I'm ignoring this one in this report since usually is related with the middle-ware or the back-end as much as with the PC.

The loss of data

You can loose data because of three major reasons:

  • You didn't save it before installing the software libre system or you lost it during the process.

  • After the installation, the data is not fully accessible or usable.

  • The data was transformed into new formats and part of it have changed.

The loss of functionality

This problem is due to the change of applications and services involved in a migration process to software libre. Is also common in other processes, but in this one is critical.

The reduction of performance

Is common to think that Linux desktops are lighter than Windows but there are scenarios where this is not always true. Most of the times any reduction of performance is unacceptable. There are technical, economical but also psychological implications related with performance that have to be studied in detail.


So computers, apps, data, users and the interactions among these four variables must be carefully analyzed before writing down the project. How to collect and analyze this information is the first step of any migration process. I (and the hold team I've been working with) have spent most of the last 7 months collecting data, thinking about these risks, developing a methodology to do it and trying to find out solutions to be able to write down the best migration projetc possible for different public administrations from the south of Spain.

I've learned a lot.