Novell Home

This series of articles over the last few issues have been focused on the Novell Open Workgroup Suite. The underlying theme has been on using and implementing the technologies in the Novell Open Workgroup Suite as you transition your servers and desktops (all or in part) to Linux. I've given realistic steps that will help you successfully make the transition.

The first article in the series helps you understand that you have a choice when it comes to desktop and server operating systems. It talks about getting all systems under management by deploying the ZENworks agent, collecting a comprehensive hardware and software inventory, and securing the desktop environment by implementing system-wide patch management. The second article in the series focuses on the migration of servers and workgroup services to Linux, based on the technology included in the suite.

In this article, I outline the steps to begin the transition to open source or more flexible, cost-effective applications on Windows. I focus on gathering application data, building your application transition map and developing your application roll out strategy starting with open source equivalents to existing proprietary applications that run on a Windows desktop, such as 2.0, which is included in the Novell Open Workgroup Suite. In the final article of the series, I'll build on the transition of desktop applications and finish the migration story by discussing SUSE Linux Enterprise Desktop and how to make the final transition from Windows to Linux.

It's Not All or Nothing Anymore
What do you think of when you hear the words "open source" and "Windows" in the same sentence? To many, that statement is an oxymoron. It's like trying to mix oil and water. But the reality is that there are many open source and standards-based applications that have been written to run on Windows, the majority of which have also been written to run on multiple platforms. Through strategic implementation of open source applications, it's possible to save a lot of money by replacing expensive proprietary applications, such as Microsoft Office, with free open source alternatives that really work. You can also improve the security of your desktops by replacing less secure applications with more secure open source alternatives. For example, you can replace Internet Explorer with Firefox. This article is focused on the process of implementing open source applications on a Windows platform, and will help prepare you to move your desktops all the way to Linux.

It's All About the Apps
Working in IT is really about minimizing disruption while maximizing productivity, all at a reasonable cost. Sometimes, to improve productivity or reduce costs, some disruptions might be necessary; however, the mantra of minimizing disruption can be very hard to follow during a significant upgrade or migration. In fact, swapping out or migrating applications (or platforms for that matter) is probably the most disruptive IT activity, short of full network shut down for system maintenance; however, it is possible to maintain the mantra ideals through a major transition with good information, detailed up-front planning, top-down executive buy in, a successful pilot, proper use of technology and good people management skills.

Desktop Control And Sanctioned Applications
Different organizations have different policies for application installation and usage. Some policies are very open, letting users install and use applications as they want. Others are very closed, where users can only use the applications made available to them. Organizations that have already implemented ZENworks, or which take advantage of the ZENworks 7 Suite included in the Novell Open Workgroup Suite to lock down their corporate desktops, will find the process of migrating to open source applications fairly simple and straightforward. And those who have a standardized corporate list of sanctioned applications will find it even easier, because the list of applications to migrate will be much shorter.

Asset Inventory
The first article of this series explains the Asset Inventory component of ZENworks 7 that is included in the Novell Open Workgroup Suite. It details the benefits of collecting a comprehensive, company-wide inventory and why it is important to bring all computers under management. One key set of data collected as part of the Asset Inventory is a list of all the applications installed throughout the environment, and where they are installed. This list is vital to a successful open source application transition. With a comprehensive list, determine which applications will easily transition, which will require some work, and which might have to remain for the time being. Also, identify low-hanging fruit, or users who can be the first to migrate to Linux in the future. Perhaps it's call center employees or fixed-function workers who use few applications. In any case, this inventory step can help you map out a sensible strategy not only for application migration, but also for initial Linux desktop pilots.

Collecting Real Application Usage Data
Two additional components of ZENworks Asset Management, which are not included in the Novell Open Workgroup Suite, will be beneficial in your transition to open source applications and a Linux desktop: the Software Compliance and Software Usage components. The Software Compliance component lets you track, allocate and reconcile software licenses. (See Figure 1.) The Software Usage component lets you collect data on actual usage patterns of installed software. (See Figure 2.) Because Asset Inventory is included as a part of the Novell Open Workgroup Suite, you can upgrade to the full Asset Management Suite (about $17 per device) depending on your licensing agreement. For more information regarding the Asset Management Suite see Software Usage Analysis: A Key to IT Cost Savings in the June 2006 issue.

Building an aggregate view of all installed software coupled with the corresponding license and usage information provides you with important and valuable application data. It will:

  1. help you to build your transition proposal and justify the cost of transition through license retirement.
  2. help you build an application transition map. (See Table 1.)
  3. give you valuable insight into how easy or difficult the application transition will be on Windows (and on to Linux, if that is your goal).

If you don't use the two additional components mentioned above, you still need the application licensing and usage information. Gather it using departmental surveys based on your Asset Inventory information. Have users verify their:

  • usage of the applications found on their workstation
  • frequency of use
  • functional usage, for example, document creation v. viewing
  • functional importance to their job.

Also determine any application dependencies prior to migrating.

Understanding Application Dependencies
To make a successful transition, you must know of any application dependencies in your environment. For example, SAP and PeopleSoft are heavily dependent on MS Excel. Some client-server applications have "thick" clients with versions that run only on Windows. Others have Web client alternatives. Some departments have invested in customized macros (Office programming) that might require new development efforts to ensure consistent functionality using the open source alternative. The more you can learn before the transition, the more smoothly the transition will go.

Build an Application Transition Map
Once you know the extent and usage of the applications in your environment, plan how your transition will take place by building what I call an application transition map: a document that prioritizes all of the applications in your environment and maps each to its corresponding open source (or otherwise-preferable) alternative. (See Table 1.) Include answers to the following in your application transition map. Is there:

  • a Linux version of the application?
  • a Web-based version of the application?
  • an alternative application that provides equivalent or better functionality or security at a lower price?
  • an open source application that provides equivalent or better functionality or security possibly for free?
  • an open source alternative that runs on both Linux and Windows?
  • a cross-over alternative needed if you plan to migrate the desktop all the way to Linux? (See Crossover Alternatives.)

Table 1 — An Application Transition Map can help you plan how your transition will take place. To create one, prioritize all the applications in your environment and map each one to its corresponding open source (or otherwise-preferable) alternative.

Application Transitional Map

Priority Application Version Linux Version Web Version Alternative Windows Alternative Linux Cross-over Needed?
1 MS Word 2003 No No OO.o 2.0 Writer OO.o 2.0 Writer No
2 Internet Explorer 6.0 No N/A Firefox 1.5 Firefox 1.5 No
3 Exchange Client 2003 No Yes Novell GroupWise 7
Thunderbird 1.5
Novell GroupWise 7
Novell Evolution 2.6
Thunderbird 1.5

An application transition map can literally become the roadmap that guides your application transition from proprietary to open source (and from Windows to Linux). Several Novell Connection articles outline a myriad of open source applications that can be used on both Windows and Linux, including ones that Novell has rolled out internally (see Enjoy the Sensation and The Abundant Open Source Apps in SUSE Linux Enterprise Desktop 10, both published in the Q3 issue. In addition, many resources on the Internet can help you build an application transition map. Two sites in particular are:

Piloting Successfully
Anyone who has ever participated in a pilot program knows that for the pilot to be successful, it needs to have a narrowly defined scope and well-defined goals or critical success factors that are easily measured. Start with a small group of the highest priority applications, or those with the most feasible open source or other alternatives. These might include office productivity, e-mail and browser applications. While there are many other open source applications that could be added to the pilot, it's best to limit the number of applications to a manageable group, thus minimizing the change impact and learning curve on those who are participating in the pilot. You might also want to limit the number of people who participate in the pilot initially.

Pilot Goals and Success Criteria
In a pilot, you're not necessarily looking to see how fast you can get the software deployed. Rather, you're trying to understand the process, impact, timing and quality issues that will help you when you begin your full rollout. During the pilot, build your application objects in ZENworks to effectively roll out the new applications. Track the number of defects or helpdesk calls as they relate to rolling out the new applications, so you can work out the kinks prior to the full rollout. Start with the IT department so they will understand what the end users they support will be experiencing. Include the executives and managers in the pilot so they buy in to the application transition and lead by example when the full rollout happens. It will also provide a glimpse into each of the departments, and the application dependencies that might exist.

Dual Install vs. Cold Turkey
As part of your pilot plan, determine if you'll uninstall existing apps when you install the new ones or if you will leave them installed for a time. There are pros and cons to using a time window. If you leave both applications installed, users aren't forced into the new application and can ease through the transition at their own pace; however, one man's 'pro' is another man's 'con.' Most users will migrate to the new application more quickly if the old application isn't still around to distract them. Also, the transition time will be shorter because the need to learn and move on will be greater. During the pilot, try both options and see what works best among different types of users. If you implemented the Software Usage component of ZENworks, run reports during the pilot to determine the frequency of use of both the old and new applications for those who had both installed.

Rollout Realities
Once you have a well-documented pilot under your belt, with happy executives and managers, it's time to figure out how best to extend the pilot to a full rollout. Depending on your corporate culture, you might be able to move from pilot to rollout, with little pause in between. But for some companies, when the pilot ends, technology will take a back seat for a while, as the IT department gears up on its 'sales and marketing' skills. For some organizations, the success of the rollout will be wholly dependent on how well and how often the goals of the rollout are communicated. You might have to promise up front that you'll provide education and training to make the rollout smooth. You may need to use multiple forms of communication (e-mail, posters, flyers, departmental announcements, drop cards on desks, interoffice e-mail, etc.) to ensure everyone gets the message. You could form focus groups, have departmental round tables, and spend a lot of time hand-holding people throughout the process, especially if a department has special application dependencies that might require retraining or new development, such as migrating complex functions from Excel or macros from Word; however, if you can't determine the level of interaction and communication with users that would be most effective, my advice would be to over-communicate until they say 'uncle!'

Choosing Your Deployment Strategy
When you plan your rollout strategy, find the best method for sequentially targeting end users. You can slice this many different ways. You can roll out the new applications by department, using the manager from the department as the focal point. You can roll them out by function, using the executive at the top of the functional unit and all of the managers that were included in the pilot to provide motivation and communication. You can also roll out the applications by geographic location, because the actual version of the application might differ depending on whether it is localized or not. You could also roll out one application at a time in sequence. However you choose to implement your rollout, remember three things:

  1. Start small (don't bite off more then you can chew).
  2. Communicate and collect feedback before, during and after the rollout.
  3. Most important, don't break the business!

Not breaking the business means you should be especially careful when migrating applications that have a direct impact on the core aspects of the company.

Will Applications Transition Smoothly?
Obviously, functionally equivalent open source applications are not 'exactly' the same as the ones they are replacing. Depending on your company, or a specific department, this might not be an issue. For most users, a browser is a browser is a browser. The same is true for word processing programs; however, you may have a small number of users in certain organizations upon whom the impact will be greater when transitioning applications. Each application might present unique challenges that impact your deployment strategies. By reviewing the differences between each open source and proprietary application, you will be better prepared for the transition. You might have to make special provisions to smooth the transition for some users. For example, let's look at the MS Word 2003 to Writer transition. The following shows what items might show up in your analysis:

Application: 00.o Writer from MS Word 2003

Table 2 — An Application Evaluation Table identifies the differences between proprietary applications and their open source counterparts, allowing you to put strategies in place to smooth the transition when necessary.

Application Dependencies

Customizations to MS SQL and IIS

Application Customizations:

  • Toolbars
  • Custom Dictionaries
  • Print Options
  • Display Options
  • Spelling and Grammar Options
  • Default Template
Advanced Features:
  • Advanced Custom Macros

Upon analysis, some items might require retooling, new integration strategies or education. Knowing this will help you set the overall expectations for end users and upper management regarding the transition of this application.

For example, although the interfaces of and MS Word 2003 are quite similar as you can see in Figure 3a and Figure 3b, the customizations your users have made to the interface might become a concern for them. To help in that arena, Novell recently announced a partnership with a company called Versora. Versora has a product named Progression Desktop that helps you to collect all the settings and customizations from MS Office, and, in conjunction with ZENworks, apply those settings and customizations to 2.0. It will do the same for transitions from Internet Explorer to Firefox. Using Progression Desktop as part of your rollout can shorten the learning curve and increase the satisfaction of your end users. And, the beautiful thing is that if and when you decide to take your users all the way to a Linux desktop, Progression Desktop will take those same user settings to Linux. Visit for more information.

Training Sources and Options
During the pilot phase, determine areas where training and education are needed. You can leverage many resources for, some of which are free. The format of the training provided by the IT department can be as simple as a new feature card left on a person's desk. You might find that eLearning is appropriate for a particular target group. In some cases, using a physical instructor who can both educate on the new applications as well as reinforce the key messages for the change might be best. Many organizations use a 'train-the-trainer' approach where key people are brought together and trained in depth. They, in turn, go out and train others. This can be very effective when you are rolling out applications to a large number of users in different geographic locations. A combination of approaches will most likely be the best option, as different people learn in different ways at different rates.

By doing a quick Google search, I found the following sources specifically focused on providing free training and resources for the software:

In addition to the free sources, thousands of additional Web sites offer training resources you can purchase.

Taking the Human Factor Into Account
As you develop your rollout strategies, don't overlook or downplay the 'Human Factor.' Most people don't like change and unless they can see a personal benefit, they'll oppose it. Generally, when change is introduced, people will follow what I call "The Negative Change Impact Curve." (See Figure 4.) Whether you're tracking Morale, Productivity or Relative Financial Impact, the expected outcome from a corporate-introduced change event is to improve the current situation. But most improvements require investments. In this case, the investment is in your end users.

Remember, the goal in IT is really about minimizing disruption while maximizing productivity, all at a reasonable cost. To do this during a period of change, IT should be focused on reducing the depth and width of the chasm caused by the change. In other words, flatten out the change curve. Just prior to a Change Event, rumor and speculation usually run rampant. To minimize this stage, IT and management need to communicate the goals of the project and give as much information as possible. Those who enter the Disbelief/Denial phase will seek to avoid the change. The departmental or group manager is the key during this phase to bring the group together and reaffirm the purpose of the change. They will also be a role model, because they will have already experienced the change. If the previous strategies don't help users jump to the Commitment phase, they will enter the Anger/Frustration/Resistance phase. Use the training and reinforcement tools to quickly move users out of the change chasm and into the desired improvement phases. Remember, the relative improvement measurement is based on the specific, measurable criteria outlined in your proposal that validates the success of your project upon completion. Don't forget to communicate the learning and success as you move through the process.

Cross Over Alternatives

Sometimes, you can't migrate a particular application to run on Linux. When this happens, you can still get this application to work in the new environment. See the table below for possible cross over alternatives.

Run Windows Application
a Browser Front End
See if the application can be run as a server-based application with a browser front end.
Run Windows Applications
Access and run Windows applications through Windows Terminal Server and rdesktop on Linux or an equivalent like Citrix.
Run Windows Applications
Run the Windows applications on Linux by using software that translates Windows APIs correctly, such as WINE or CrossOver Linux.
Run Windows Applications
Embed a Windows Virtual Machine on Linux to be launched when the particular application is needed. VM Ware now has a free VM Player, making this alternative much more attractive as long as the machine has enough computing power.
Run Windows Applications
When an application is rarely needed, but needed none the less, you can set up the machine with a dual boot between Linux and Windows.

Next on the Horizon
In this article, I have outlined how an organization can implement open source or more secure, cost-effective application alternatives in their current Windows environment using the technologies and solutions included in the Novell Open Workgroup Suite and applications available from the open source community. In the last article of the series, I'll outline the final steps toward transitioning completely to a Linux desktop. So stay tuned. EndOfArticleRedN

© 2015 Micro Focus