Editor's note: This article is Part 2 of a five-part series. See the other developerWorks articles in the series: "IBM open collaboration client solution: An overview," "IBM open collaboration client solution: Technical planning," "IBM open collaboration client solution: Migrating business applications to the Linux desktop," and "IBM open collaboration solution: Architecture decisions and execution options for an IBM open virtual client."

Introduction

Migrations on the client-side are challenging due to their large scale, the potential uniqueness of each client system, and the direct effect on users. This article focuses on the starting point of a client migration: that is, the organizational planning and especially the user segmentation. It also offers a method to identify the most appropriate user segment that should be migrated first. Our systematic approach is based on several recent customer migration experiences. The technical planning process that seamlessly follows the organizational planning is the subject of the next article of this series.

Back to top

Getting started

This article is based, in part, on the organizational planning section of the IBM® Redbooks® publication, “Linux Client Migration Cookbook, Version 2: A Practical Planning and Implementation Guide for Migration to Desktop Linux," and is enriched with many additional real-life experiences. If you'd like to delve further into the client migration process, we recommend the IBM Redbooks publication.

Before beginning any migration to client-side Linux, you must first determine the most appropriate strategy and user segmentation, based on the following factors:

• Your final objectives and schedule
• The size of the client environment to be migrated
• The available staff and/or manpower
• Other factors applicable to your current project, such as the Sarbanes-Oxley Act or the Basel II accord for the finance sector

Today's literature, cited in the Resources section, discusses three important migration strategies:

• Big Bang. Also known as "All or Nothing" or "Point-in-Time"' migration.
• Incremental. Also known as "Staged," "Step by Step," or "Chicken Little" migration.
• Parallel. Also known as "Eco" migration.

These strategies have widely different characteristics with respect to migration effort and migration period, as shown in figure 1.

The main characteristics as well as selected pros and cons of each strategy are listed in table 1.

If your focus is mainly on enterprise-scale (or at least midsized) accounts, the incremental migration strategy usually fits best because it's the most economical. The other two strategies go beyond the necessary scope with respect to the preparation effort and the required resources, including personnel.

For the incremental approach, the migration must be broken down into manageable parts. In the case of users, this approach means breaking down the total user set into reasonable segments. We focus now on the user segment to be migrated first or to take part in a pilot.

To make the migration successful right from the start, it makes sense to migrate the easiest user segment first, documenting your experiences, testing the back-end systems, and incorporating feedback from pilot users before continuing. But first, you must keep two important items in mind before starting:

1. The functional continuity of each individual user must be retained (explained later in this article).
2. Interoperability must be ensured between all user groups and segments participating in the pilot (explained in the next part of the article series).

The initial user segment participating in the first pilot can be defined by, for example, the following:

• The type of users
• Their job role
• Office location
• The department
• The project that the users are currently working on
• The use of certain products, for example, Microsoft® Office
• Combinations of the preceding factors

Depending on the specific project constraints, it can make sense to select a group of users for the pilot that embodies either of these characteristics:

• Self-contained and easy-to-migrate. This approach allows you to harvest the low-hanging fruit by migrating a simple user segment first. The important result is that you realize immediate savings, freeing up funds that can be put toward the remainder of the migration. This approach can be viewed as the "foot in the door" approach.
• Scattered. This approach does not lead to immediate savings, but it covers more user types, and the pilot migration more closely resembles the later main migration. This approach can be viewed as an information-gathering exercise.

Regardless of the option that you choose, after the migration, the pilot must demonstrate the following:

1. Users are able to perform all their duties and use applications as they did pre-migration.
2. Users are still able to access the organization's infrastructure.
3. All administrators are still able to perform their same tasks.
4. The new components are functioning as planned (the server and client hardware and software and their integration might need to be checked).
5. Everyone is still able to follow the existing guidelines, procedures, and processes (or are adjustments necessary?)

The remaining sections of this article present a method to determine the best user segment for a pilot migration, including addressing the first four points above. The complexity and broadness of the last point make it nearly impossible to prove, without looking into the details of your specific project. Because each job role can require different guidelines, each company has different sets of guidelines. Moreover, each country and geographical region require compliance with still other guidelines. That's why the last point is not considered here.

The general organizational planning process, of which user segmentation is an integral part, starts with an assessment, as diagrammed in figure 2.

Let's now discuss these steps in more detail.

Back to top

Classification and segmentation

When performing a pilot, or any migration, you must clearly understand the entire IT environment, including all users' applications and usage patterns. The best way to gather such information is to perform an as-is analysis that helps yield a segmentation according to role-based usage patterns.

The following three sections describe the analysis for desktop market segments, user segment definitions, and the functional segmentation. The key objective of this last section is to obtain the details for a functional segmentation that lets us sort the entire set of users according to their role and function.

Back to top

Desktop market segments

The desktop market is much broader than the server market. There are considerably more applications available, and many people tend to use their own subset of applications with personal customizations. According to the product portfolio used, the desktop market can be roughly grouped into these segments: fixed function, technical and transactional workstations, basic and advanced office, small and home office, and consumer, as shown in figure 3.

The rather simple segments of the desktop market (fixed function, technical and transactional workstations, as well as basic office) cover only a limited set of standard applications. The threshold from the simple to the advanced desktop segments [advanced office (power users), small office / home office, and consumer] is mainly defined by the exploitation of a broader range of office functionalities, especially templates, forms, and macros.

Back to top

User segment definitions

Organizations such as IBM and the analyst firm Gartner, Inc. base their user segment definitions on the known desktop market segments and additional industry surveys. Figure 4 shows IBM's user segment definition as compared with Gartner's.

The proportion of the user population is similar in both approaches -- only the amount and the weight of the segments are different. This similarity is not surprising because the data was gathered with the help of various surveys and followed by statistical purifications. The aim of IBM, especially with respect to its open collaboration client solution (OCCS), is to cover all segments, including some parts of the advanced office segment.

To sort a set of users into the appropriate segment, you need a more detailed description of the segments, including more information about their functions. Figure 5 provides a reference table that you can use as a guide for a functional segmentation. Keep in mind, however, that some users might fit into more than one segment or that segments might be missing or nonexistent in your organization.

An in-depth explanation of the client types (first row in figure 5) and their functions, including sample applications areas for the remaining rows, can be found in Appendix A.

We got a first impression of the user distribution by performing an initial assessment of the clients' usage patterns, classifying the users and segmenting them according to their function. This assessment allows us to take a quick look at the expected costs. The more users that are sorted in the columns on the right side of figure 5, the more costly the migration will be.

It is therefore recommended that the pilot user group have the following traits:

• It should be part of one or a few columns on the left side of figure 5.
• It might contain a few users that are part of the segments of the right side, which allow you to preview some hard-to-migrate users during the pilot.
• It should not be part of multiple columns in figure 5, to reduce the complexity of the pilot.

Back to top

Surveying user data

The next step is to finalize the user segments by gathering all remaining information about each user, including his or her workstations' hardware, software, and usage profiles. In well-organized institutions, such information might be readily available, at least in part, and can be obtained from a central repository. Real-world experiences show that, for example, in companies that are rapidly growing or that have made some acquisitions, a survey is virtually inevitable.

Furthermore, the survey provides knowledge of existing applications, tools, hardware, software, and other items such as the file types used or dependencies on other systems not listed in any repository but still important for users.

Sample hardware survey

We recommend that you perform surveys for hardware as well as for software. The hardware part of the survey can be the smaller one and includes the main information about the hardware, its function, operating system, options, and further comments.

Because nontechnical users are reached by the survey, it's a good idea to distinguish between mandatory (red) and optional (gray) fields, as shown in the sample spreadsheet in figure 6. The migration staff might be able to fill out any remaining blank fields later, based on the mandatory input or after a call-back. The survey should at least include information on how to determine the data for the mandatory fields, to support the non-technical users.

Sample software survey

The software part of the survey is usually bulky due to the large number of client applications; however, the questions for each application are fewer. Figure 7 depicts a possible software survey.

To minimize the disruption of users' resources, you should combine both surveys into one spreadsheet to minimize the content. To get the most out of the surveys, you can add more questions to gain more insight into the users' points of view; however, you must balance this addition with the time and effort expended.

This as-is analysis of the current user IT infrastructure serves as input for the simplification task discussed in the next section and later as the basis for establishing functional continuity, which again emphasizes the importance of the user data and the survey itself.

Back to top

Simplification

The simplification task reduces the amount of applications within each functional segment and simplifies the target IT infrastructure and landscape. It is performed by the identification of the minimal subset of applications used by each functional segment, which covers at least the minimal required functionality.

We strongly recommend that you perform this step at this point of the process because it leads to benefits in all subsequent steps, allowing you to deliver only what is really needed. It allows you to do the following:

• Control and reduce costs
• Control and reduce complexity
• Control information flows and operational efficiency
• Provide the ability to avoid vendor lock-ins with particular applications
• Determine the function and the cost of the client, based on the infrastructure used (including the applications employees need for their roles)

Unfortunately, this task is not easy; for example, difficulties may arise from political conflicts between different teams and departments of the organization. Nevertheless, you can realize huge benefits from this task – not only for the organizational planning, but also for the rest of the migration, down to operation and maintenance. It is important to perform the simplification task, even if you need the help of the higher IT management to do so.

Simplification of graphic applications

Using the functional group Graphic from table 3, this example shows how to reduce the set of graphic applications used and how to find a common set of applications that still provides the necessary functionality. In practice, you should do this ftask or as many functional groups as possible.

First, extract a spreadsheet about the functional group Graphic out of the software part of figure 3's spreadsheet (see figure 8).

Now enrich this spreadsheet by adding data that answers the following questions:

• Is the listed product a multiplatform application that also supports the new target Linux operating system?
• Is there a bridging application available that is capable of replacing the listed product?
• Is there an alternative application available that provides a functional equivalency?

A typical multiplatform application is IBM Lotus® Notes®, which since version 7 is based on Eclipse and inherits its platform independence from it. Version 8 of Lotus Notes is therefore natively available for Microsoft Windows, Linux, and Macintosh OS-X.

Bridging applications allow for application migration before the actual platform migration itself. The advantages are that users migrate in smaller steps and do not experience too many changes at once; they become familiar with new applications before the actual migration occurs. An example of such a bridging application is OpenOffice.org Writer or even the whole OpenOffice.org suite. If you want to move from a Microsoft Windows desktop to a Linux-based desktop and use Microsoft Office for office productivity, you might move to OpenOffice.org before the main migration.

Users are then able to become familiar with OpenOffice.org and, when the main migration occurs, they can focus on getting to know the new platform only and do not need to care about changes in their office productivity tools at the same time. Bridging applications are inevitably multiplatform but are not already in use, so Lotus Notes can also act as an bridging application.

Finally, functional equivalents of applications are alternatives for tools and applications of the original platform that have no direct, one-to-one counterpart on the target operating system. Such a gap can occur due to any of these reasons:

• The developers are focusing on only one platform.
• The applications are programmed for a specific operating system.
• There is no (or little) need to have them available for the target platform.
• No one has ported that application yet.

The spreadsheet in table 4 now must be expanded by three columns for the three types of applications (see figure 9), and the additional cells must be filled in according to the examples shown previously.

Now that we have all the information for the simplification, we can easily identify the products with the best coverage. In this example, GQview has the broadest coverage for the picture-viewing functionality: Gimp for raster graphics and InkScape for vector graphic handling. If there are no other reasons that argue against these applications such as licensing issues or instability, the spreadsheet can be simplified as shown in figure 10.

The nine products listed in the left-most column that we've used so far can now be replaced by their three functional equivalents listed in green in the fifth column. Note that a functional equivalent need not necessarily be a product that has the same or additional functionality. Rather, a functionally equivalent product offers equal functions to those currently used. Remember that usually only a limited amount of the total functionality is actually used; in the case of office functionality, this averages less than 10 percent.

Back to top

Functional continuity

Now that we've simplified the applications landscape and removed some complexity of the software spreadsheet, it is important to ensure that no functionality is lost during the migration. The point here is to retain the current functionality of the application landscape and thus avoid a loss of productivity. To retain the functions of all currently used applications, we must find a migration path for all required applications based on the remaining columns of the spreadsheet.

We already started looking for functional continuity in the previous section by adding three columns. This step worked toward establishing functional continuity, but it's not sufficient. If no multiplatform, bridging application nor its functional equivalent is available, we must look for other alternatives, which are the last columns to be added to the spreadsheet:

• Web-based alternatives. Some vendors support only a few operating systems for their applications. The rise of Linux as an additional desktop operating system, though, has led these vendors to make their applications also available for Linux. Customer Relationship Management (CRM), Enterprise Resource Planning (ERP), and Human Resources (HR) applications are examples. To port their application (at least the client part) to a new operating system such as Linux, vendors often introduce a new client as a Web-based application. With such a browser-based solution, they avoid the ongoing support for many different client operating systems while giving customers more flexibility and partly avoiding a vendor lock-in (at least for the client operating system).
• Terminal server alternatives. This term means that the initially used product on the original operating system is still in use, but that it's running, that is, "hosted," on a terminal server instead of directly on the client. The terminal server provides remote access to the product, which can again be used on the client with the help of a special terminal-server client or sometimes simply by a Web browser. Such terminal-server clients are merely lightweight products that are available for many different client platforms, and sometimes also as a Web browser plug-in. Examples of terminal-server solutions are the following:
  
  
  • Microsoft Windows Terminal Services. Uses the remote desktop protocol (RDP).
  • Citrix Metaframe. Uses the Independent Computing Architecture (ICA), Citrix Systems' thin-client protocol.
  • NoMachine NX. Uses a meta-protocol (NX protocol) that is able to tunnel and compress, along with some other protocols such as the X protocol, RDP, and Remote Framebuffer (RFB; used by Virtual Network Computing), and uses Secure Shell (SSH) for security and public keys.
  • Desktop Virtualization. For example, VMware's Virtual Desktop Infrastructure (VDI) makes applications available that run locally or remote on internal virtual machines but can be accessed through common protocols such as RDP; some virtualization solutions that are targeted to run on workstations only, such as VirtualBox, also offer a functionality called seamless windows.

Certainly the biggest disadvantages are the added complexity and costs for the additional infrastructure, including hardware costs for the terminal servers and possibly costs for the required software, if no freely available solution is used.

Back to top

Typical desktop applications

The spreadsheet in figure 11 shows an example of a Web-based alternative to Microsoft Outlook Express, as well as the Siebel CRM client, which is made available with the help of the Citrix Metaframe terminal server product.

Back to top

Further considerations

Now you can understand the feasibility of a migration from an application point of view by looking at the entirely filled spreadsheet (see Appendix B). A migration can also be a good time to consider shifting paradigms. For instance, it might make sense for your organization to herald a new trend by moving to browser-based applications in general. Figure 12 provides a rough overview of the cost, flexibility, and manageability aspects of the target applications, which are listed in the two new right-most columns.

Back to top

Social considerations

Here we raise awareness of some nontechnical aspects that are not necessarily obvious and that tend to be underestimated by technical people: the social factors. These factors are especially important in a client migration project because users are affected in such a direct way.

Human factors

Fundamental changes in the way that users work, such as having to use new client interfaces or adjusting to completely new behaviors of their familiar tools, often cause frustration for most nontechnical users. To avoid this situation, it is crucial that you run the migration smoothly, for example, by using bridging applications and by involving users right from the beginning. This involvement can simply be establishing a communication plan or requesting and incorporating feedback from users, up to voluntarily participating in the pilot migration.

All this is aimed at eliminating negative aspects of the user acceptance curve, shown in figure 13.

Retraining aspects

Even if it is possible to find many multiplatform and bridging applications, user retraining is still required in many cases. At a minimum, retraining typically covers the following items:

• Learning the new look and feel of the desktop
• Learning the new behavior of the desktop and its applications
• Becoming familiar with actions, locations, and names
• Offering hands-on use of the new target environment
• Becoming familiar with multiplatform-capable applications
• Using bridging applications to ease the migration from a user's point of view and to separate retraining from migration

Even if training classes are expensive due to the loss of productivity, the need for rooms and trainers, and travel costs, they can lead to increased productivity in the long run. Also, special training might be required for difficult-to-migrate or even un-migratable applications, as well as for post-migration tasks such as troubleshooting, support, or the help desk.

Back to top

Conclusion

This article walked you through the steps for planning a migration to a Desktop Linux environment. First, we performed an assessment and classified the users, according to desktop markets and user segments that are defined and well known in the industry. We substantiated this segmentation by taking a closer look at the clients' functional needs and usage patterns.

To gather more detailed information, we began an as-is analysis in the form of a user survey regarding data about hardware, operating systems, and software. The software data was then used as a foundation for simplifying and establishing the functional continuity. For the simplification step, multiplatform and bridging applications and functional equivalents were introduced. Web-based and terminal-server alternatives were introduced to provide two potentially new migration paths. The move to Web-based alternatives offers the best flexibility on the client side, but it requires additional effort on the server side. Last, we discussed some important social considerations regarding the involvement of the users and their retraining.

After developing the functionally segmented users and knowing their entire application portfolio, you can plan and organize your migration, systematically choosing a segment for a pilot migration that is suited to your project needs. Example segments can be a self-contained group of users, an easy-to-migrate group of users, or preferably the most representative group of users. This information provides for better estimates of the target client environment, its manageability, its maintainability, the expected costs, and other risk factors.

Back to top

Appendix A. Client types

The following is a list of the client types discussed in this article:

• Fixed function. Users of these client systems run only one designated application, and applications are customized for specific use.
  Examples: Kiosk or point-of -sale terminals, WebSphere® Portal-based applications.
• Technical workstation. Users of these client systems work on industry-specific applications. They might require specific software packages, tailored to a sector or problem domain.
  Examples: Engineering (such as CAD/CAM applications) or entertainment applications (such as film animation).
• Transactional workstation. Users of these client systems run form-based applications; additionally, they browse intranet and simple Internet sites, and they process simple email. Applications are customized for specific use, and email does not include attachments.
  Examples: Travel agency workstations, bank teller workstations, front office workstations.
• Basic office workstation. Users run business applications necessary to drive the company business processes (for example, ERP, SCM); they browse intranet and simple Internet sites, collaborate (using instant messaging) within the company, and process simple email. Also, they run applications to create and view simple documents (for example, memos, letters, spreadsheets) for use within the company only, in portable formats (PDF, RTF, HTML). Email involves attachments, and users need to print files that they receive.
  Example: Loan officer workstations.
• Advanced office workstation. Users run the business applications that drive the company's processes (for example, ERP, SCM, software development tools); they browse intranet and simple Internet sites, collaborate (using IM) within the company, and process simple email. They also run applications to create and modify complex (compound) documents for use both within and outside their company. These applications involve advanced office productivity features such as charting, formatting, or embedding; retaining data format while exchanging files is very important. Users of these client systems also download executable binary files from the Internet.
  Examples: ISV software developer, retail back-office worker.
• Developer workstation. Users must run and test any application for their specific operating system natively because they test and develop applications. This workstation can also apply for home office users, services professionals, or others.

Additional information can be found in the "Linux Client Migration Cookbook, Version 2: A Practical Planning and Implementation Guide for Migration to Desktop Linux,” chapter 3.1, page 55.

Back to top

Appendix B. Entire spreadsheet example

Resources

• Refer to the previous developerWorks article in this series, "IBM open collaboration client solution: An overview."
  
  
• Read part 3 of this developerWorks Lotus series, "IBM open collaboration client solution: Technical planning."
  
  
• Read part 4 of this developerWorks Lotus series, "IBM open collaboration client solution: Migrating business applications to the Linux desktop."
  
  
• Read part 5 of this developerWorks Lotus series, "IBM open collaboration solution: Architecture decisions and execution options for an IBM open virtual client."
  
  
• Read about the IBM open collaboration client solution.
  
  
• Refer to the IBM Redbooks publication, “Linux Client Migration Cookbook, Version 2: A Practical Planning and Implementation Guide for Migration to Desktop Linux."
  
  
• Refer to the IBM Redbooks publication, “Migrating from Microsoft Exchange 2000/2003 to Lotus Notes and Domino 7."
  
  
• Read about the IBM open collaboration client solution powered by SUSE Linux Enterprise from Novell.
  
  
• Read the IBM white paper, "IBM Point of View: Desktops of the future and how to get started today."
  
  
• Read the developerWorks Lotus article, "Developing and deploying rich client applications on desktops and mobile devices using Lotus Expeditor V6.1."
  
  
• Read the developerWorks Lotus article, "Building an offline application in IBM Lotus Expeditor."
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Getting started
• Classification and segmentation
• Desktop market segments
• User segment definitions
• Surveying user data
• Simplification
• Functional continuity
• Typical desktop applications
• Further considerations
• Social considerations
• Conclusion
• Appendix A. Client types
• Appendix B. Entire spreadsheet example
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Lotus on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers