President's Perspective

IT migrations: moving to a better place

In stride with the theme of this quarter's publication, I thought I would contribute some thoughts about the subject of migration. Please trust that Datatrend has vast application migration experience with dozens of projects under our belt. So there is some experience those interested in migration assessments/work can tap into. A total migration solution includes more than a port from x to y. Our migration project office designs a solution and tailors each approach to the specific client project and specific application priorities.

Migration need not be other than a positive experience, if migration is appropriate. With proper front end assessment work, all that follows is easier than the alternative of a short-cut effort in quest of complete and proper scope definition. It is not about migration; it is about migrating the application and dealing with all ripple effects. All ripples are not bad nor migrate into 20 foot grey waves of doom. When migrating an application, other issues need review and addressing.

Migration can mean different things to a variety of IT or line of business professionals:

• Data migration where OS and code base remain the same

• Changing the brand of incorporated relational database management system

• Moving from one OS to another but keeping the same code base

• Changing the code base of the same OS with some version upgrade, perhaps

Certainly, migration can also mean any combination of these scenarios. I want to underscore the difference between integration and migration. They are not the same thing, but both can be part of a project plan and occur under the same scope of work. For example, along with a code migration, we may also integrate DB2 or Oracle into a solution stack or application layer.

To migrate or not to migrate is often the question. Older applications may not be architecturally built or contain desired functionality to be competitive with new cellophane-wrapped ISV offerings. Other older applications may be reflective of years and years of well conceived customization; such functionality essential to maintaining competitive advantage for the given enterprise. Newer, off-the-shelf ISV offerings (packaged replacement options) may require years of customization and millions of dollars of enhancement work, just to get to the functionality level of the in-production incumbent application. Migration methods using translators that save substantial dollars and time may yield code structure output that people do not want to maintain and support. Independent of cost consideration and time line to complete, manual rewrite might yield the ideal end result, but how many organizations operate in a cost independent and open ended time line world?

People have to look at all the angles and factors and apply the organizationally unique considerations, in order to make the best philosophical approach to migration decision. Should one translate/convert or rewrite? Should one package replace or enhance/modify the existing application? It really depends on the factors involved and the proper weighting of the points of consideration.

Deciding to Perform a Manual Rewrite

The advantage with manual rewrite, considering a brilliant designer that has outstanding command of the best input from the given organization's line of business, finance, IT, support and end user communities.....is that one has an opportunity to develop the perfect application; however, the perfection of that application depends on the eye of the beholder. Are we talking about the group funded to develop the application? Or the users that use it? What about the group that has to support it? With manual rewrite, how does one complete on time and on budget? Ever hear of scope creep? Hint: Get the right people on the design committee, limit the time to develop the design, provide review/feedback opportunity, publish the spec, provide deadline for final spec, and get out of design mode and into development completely. If one does not do all of these things and more, your money well will run dry before project completion in the universe of manual rewrite. Oh, another thing: What good is a cheap hourly rate from overseas if that group takes ten times as long to complete the project as the domestic option with twice the labor rate? In development projects, including application manual rewrite, your cost control solution, in part, is to demand accountability and budget adherence. This speaks to working with a well funded group with an outstanding development track record and an SOW that is bulletproof in favor of the funder. Let me get back on topic.

Assessing the Option of Package Replacement

Looking at the new industry “sizzle” application candidates to replace your highly customized legacy monolithic application....is not easy. In the case of industry vertical/highly specialized applications, how do you determine, prior to investing, whether the given product will really work as you need it to? Demos are one thing and evaluations another. Even in evaluations, often time allotted and depth of evaluation is limited. You really do not know what you have until you have it. Not until you make the purchase decision, put the package into production, and gathered end user feedback, do you really know for sure what you bought. Then you begin the cycle all over again with the inevitable customization/enhancements.

A case can be made, and often is made, for comparing migration to manual rewrite or package replacement in the context of the cost, time line, and risk associated with each option. At a high level, there is often less risk, less cost and less time involved with migration. When this is not the case and package replacement is the solution, most often the legacy application architecture had some dead end aspects too costly to deal with. Or, we are talking about a simple application with not that many lines of code.

Certainly, to justify migration, over the other alternatives, and in the context of older complex legacy applications, there has to be a business set of value in the highly customized functionality, and there cannot be any technological show stoppers. I have seen some applications live on for 30 years yet were able to be enhanced to provide the desired web enablement, data sharing, and "windows-type" capabilities desired. On the other hand, there are many applications that just need to move from one OS to another and that is pretty much the scope.

Proper assessment is the key. In considering a migration, you must keep in mind:

• business drivers

• technology

• corporate standards

• support capability

• future support road map

• manufacturer long term platform commitment

• finances

In cases where migration is clearly the best solution, the question develops as to who should perform or be involved with the migration. Take the example of migrating from Sun Solaris to IBM AIX, where the code base is and will remain in C or C++, including some incorporation of Java and/or WebSphere to web enable some aspects or provide defined web based capability. Certainly, a company changing the UNIX corporate standard from Solaris to AIX will have some skill development and skill transfer needs. Contracting with a knowledgeable and experienced migration firm might be a very good idea in this case. Performing the migration on their own may challenge the internal IT group causing them to be spread too thin. However, going back to the need to learn AIX, it might be a great compromise to have the migration firm perform the heavy migration lifting, but have as members of the migration team those familiar with the application within the client organization.  Such participation can be ancillary to a negotiated and customized education and skill transfer plan.

I have seen outstanding project assessment and design work to the point where the published work is so revealing, that the client organization decides to perform the migration work totally. What I want to offer here in this migration project example is that much of the effort and initial mystery are solved during the assessment phase. At Datatrend, we call it a Logical/Physical Design Study (LPDS). The Datatrend LPDS yields a documentation set that serves as a blueprint depicting all requirements and phases of a migration including test plans, test plan procedures, beginning infrastructure, proposed infrastructure, data center/environmental considerations, training, and post migration support. This LPDS coupled with IBM's RedBook on migration to AIX, for example, is often all the client needs. Whether, the client participates meaningfully or lightly, participation enhances skill transfer or education ramp-up. Application literacy representation is key in all migrations. There is no shortcut. Someone with knowledge of the application either has to be involved or periodically accessible to the migration team. Also, often under emphasized is the need for a solid test plan. A migration firm to trust is the one that will demand user review and involvement in test plan development and actual testing. Datatrend and its partners are migration experts. No one knows the given application better than the author, the owner and the users.

Datatrend can help you determine whether migration is feasible, a good idea, or something to avoid. Please note that Datatrend will be hosting a series of migration webinars, workshops and seminars. Showcased migration depictions will include Solaris to AIX, UX to AIX, Solaris to Linux, Oracle to DB2, DB2 to Oracle, and other paths. Some of these sessions will focus on TCO advantages of one platform over another. Different sessions will contrast ancillary offerings including consolidation and virtualization and other opportunities to lower TCO and improve manageability in tandem to a migration.

IT migrations: an overview

It's no longer like pulling teeth

In the early days of IT migrating an application or a set of users from one platform to another was difficult - something you only did if you had to. That's why the term still grates with many who are longer-in-the-tooth.

However, today thousands of major migrations are happening all the time - and so they should. Given the rapid improvement of technology and the continuing explosion of price performance we should all be looking to move our value-producing systems to better platforms every two or three years. In this overview article we tackle the two fundamental questions:

• Why migrate?

• What are the keys to success?

Migration motivation

"If it ain't broke don't fix it". So, why migrate applications that are working? Let's enumerate the reasons from the simplest to the more complex:

1. Necessity: The old platforms are no longer supported.

2. Lower simple cost: The new platform is simply cheaper to acquire.

3. Lower total cost of ownership: When you include maintenance, administration, physical space, power, training and other costs the new platform saves money.

4. Better performance: The new platform is faster or more powerful in some other regard such that it better meets the needs of the application.

5. Better technology: Advanced functions of the new platform reduce costs or increase value in ways that the old platform could never match.

6. Consolidation, simplification and/or integration: Taken by itself there may not be a case for migrating a specific application. However, in the broader context there is value in consolidating platforms. This may reduce costs by focusing administration and support; or it may increase value by enabling integration across several applications.

The first five reasons have been with us since the early days of IT. However, the sixth reason was relatively unusual - until recently. The last decade has seen an explosion of servers, networks and storage subsystems - largely driven by the Internet. The resulting sprawl has generated a compelling need in many organizations for consolidation and simplification - a need that provides the financial justification for many changes. As a result, this has become a factor - even the main factor - in most of the migrations we see today; it even explains the large increase in total migrations.

Advice for migration success

So, a huge number of migrations are taking place for very good business reasons. This activity has created a wealth of knowledge and expertise on migration best practices. If you peruse the literature you will see plenty of advice from migration specialists that incorporate their keys to success. Here are examples of the typical advice you will find:

• Plan, plan, plan. Like any project, the execution is unlikely to be better than the plan. With application migration your plan must encompass accurate estimates of cost, resource, training needed and many other factors.

• Focus on the special needs of data migration - especially in the increasingly common situation where continuous operation is required.

• Perform a detailed assessment as part of the planning process.

• Ensure adequate and timely training.

• Insist on thorough testing at all stages - but especially a final user acceptance test.

We could extend this list with many other pieces of general advice. However, you have probably already noticed a common thread in this advice; it's all motherhood and apple pie! No one could argue with the wisdom of such generalized counsel but, on the other hand, it doesn't tell you what to do next; it isn't, as they say, actionable advice.

The single key to success

In our newsletter we try to provide practical ideas that you can apply right away. Applying this to migration leads to one strong piece of advice:

The key to success in migration projects is to leverage the specialized skills available.

There are very few organizations that are tackling migration projects on a regular basis; therefore, most organizations could use specialized advice or assistance. Here are some practical ways to implement this key to success:

• Take advantage of migration centers: Because of the increase in volume of migrations there are centers that specialize in specific types of migration or in the general process of migrations. For example, IBM has created a Migration Factory that can provide anything from general advice on migration projects to pinpoint specialized data on common migration paths. Many of these centers will provide initial assistance at no charge as part of their pre-sales support.

• Use specialists to help with project assessments and plans: The involvement of someone who has done 50 or even five similar projects is going to be invaluable in the formative stages of your project. You may get this help from a migration center as no-charge pre-sales support; or, you may have to pay for direct planning assistance. The value of a good plan should provide more than adequate return on this early investment.

• Consider outsourcing the specialized skills: Let's say you want to migrate some UNIX workloads to pSeries AIX. If this is something you expect to do several times in the future, then acquiring the in-house skills would make sense. But for many organizations this is a one-off project; while you want your staff to be skilled in the migrated environment, any skills acquired in the specialized processes of the migration itself will not, by definition, be useful in the future. Outsourcing these specialized migration skills fits well with the fact that most migration projects demand additional resource for the planning, migration and testing phases. It's far better to reach for help in the areas where there is value to the specialized skills and where these skills will not be directly needed again.

In summary, our single, actionable key to success is to leverage the increasing pool of specialized migration resources. As always, Datatrend stands ready to supply some of that resource and to act as a conduit and enabler to bring resources like the IBM Migration Factory to bear on your projects.

... on migration projects or how to leverage specialized migration support.

The most popular migration target

Why the rush to pSeries?

The trend to pSeries has been a remarkable feature of the UNIX market for over four years. The chart shows the resulting changes in market share. The obvious question is "Why?"

There are numerous and complex answers to this question. However, when faced with such a dramatic trend it must be possible to isolate some simple, underlying causes.

From this top-down point of view we can see two reasons why pSeries has been so successful:

• Price/performance: The bottom line in this category of servers. The POWER technology and the servers that contain it have simply provided better value - sometimes spectacularly better value.

• Sophistication: pSeries has led in advanced functions culminating in the announcement of the virtualization engine that has been in every p5 system since 2004. While raw power seemed to be the right thing for the 90s, the virtualization and integration leadership of pSeries is exactly the right thing for the consolidation and simplification decade.

Some of this market share increase results from completely new acquisitions. But, as you would expect, there has also been a demand to migrate existing applications to this superior platform. Thus, one of the most popular migration paths has been and remains from non-IBM UNIX platforms to pSeries AIX. Since the non-IBM platforms are still available and supported, this demand is not due to type A migrations (necessity).

As predicted by the above reasons for pSeries success, types B through E migrations are all strongly represented. 

Since pSeries prominence coincided with the rising need for consolidation and simplification it is no surprise that type F migrations have also been common.

Should you consider this popular migration path?

Based on such a strong, long-term market trend it makes sense for all UNIX users to review their short-term plans and their strategies. Chances are that pSeries will be playing a bigger part in both areas. As a result, migrations to pSeries AIX may well be in your future.

Applying the key to success

If the key to success we suggested in our introductory article is worth anything, we should certainly be able to show how it applies to this most popular of migrations. So, how can "leveraging the available specialized skills" ensure success in this case?

• IBM's Migration Factory has regular sessions for this common migration. General advice and orientation is made available to many customers at no charge.

• IBM has specialists dedicated to this particular migration path. They bring the experience of many successful projects to bear on specific needs.

• You can get assistance with project assessments and plans at any level of detail you need. As you would expect, once you get beyond general advice and into specific value-added work, these are normally fee services.

• If you have more pressing uses for the skills of your current staff, Datatrend can work with IBM Global Services to find specialized skills to perform any parts of your pSeries/AIX migration projects.

... on how your open systems strategy and IT consolidation progress could be affected by migrations to pSeries/AIX.

Moving to open standards

Migrating to truly open systems with Linux

For over 15 years open systems have been holding out the promise of lower costs and better standards. However, the early standard bearer for open standards, UNIX, became mired in commercial interest. Now Linux is delivering on the original promise by providing a truly open system driven by standards that are "owned" by the IT community. Migration projects provide opportunities to make major progress towards open systems in three different ways.

Revolution: Making a major leap

The need, or desire, to migrate major systems provides many organizations with an opportunity for major expansion of their open systems strategy.

Revolution 1: Edge of network functions

The most numerous examples are consolidation of edge network functions - like firewalls, virus scanners and so on; many people feel that for these things Linux not only provides lower total cost of ownership, but it is also more secure and less likely to attract attacks.

Revolution 2: Office systems - document creation, communication, collaboration

One area of particular financial attraction is office systems. The cost per desk of the leading office suite has failed to follow the industry norm for improved price-performance and now represents a major element in the IT budget. It also provides a perfect case study in why some major vendors are resisting the move to open standards to protect their own interests. However, the interest of the customer is so overwhelming in this area that, like King Canute telling the rising tide to turn back, the commercial interests will fail to resist this inevitable movement. Most organizations are back-leveled one or two releases on their office suite and will be offered yet another version upgrade in 2006 - with a massive upgrade charge to implement across the organization. These are exactly the conditions that make people think about migrating to a more cost-effective, open platform. Just in the last year we have seen major announcements that make open standards office systems migration a practical alternative for a huge number of people:

• OpenOffice version 2 was released. Despite its zero price tag, many specialists rate it as equal or even superior to the leading commercial product for the majority of office workers. Its high degree of compatibility is causing many to plan for a dual strategy: a commercial office suite for the top 5% of power users and OpenOffice for the other 95%.

• Lotus Notes/Domino version 7 was released. This provides the last pieces of Linux support that allow a total end-to-end implementation of the most sophisticated communication and collaboration systems. As a result, this is the perfect companion with which to build the most sophisticated and lowest-cost open systems using the dual strategy.

Revolution 3: Mission critical applications

So far it has only been a trickle; but the migration of major applications to more open platforms - particularly Linux - continues to accelerate. With the massive focus on SOA (Services Oriented Architecture) in 2006 we are going to see a huge number of people start to fully appreciate the practical, here-and-now benefits of open standards (unfortunately, we will also see those vendors with vested interests try to turn back the tide once again). Once people start to migrate their major applications to SOA standards, the genie will be out of the bottle and the migration to fully open platforms could become a flood.

Evolution: jumping the chasm in several small leaps

If the word "revolution" scares you there are less extreme alternatives. In fact, the power of virtual machine facilities are making it very easy and inexpensive to start small Linux projects and grow them as you acquire skills and experience.

Both the pSeries p5 and the iSeries i5 come with a virtualization engine built in. The ingenious logical partitioning will allow you to create a small Linux virtual machine for your pilot projects. With micro partitioning you need only dedicate one tenth of processor to the pilot. Then the dynamic power of the partitioning will allow you to slowly expand the resources assigned to the project as your use of Linux grows. What a perfect way to develop an open strategy alongside operational systems!

Whether you get there aggressively or timidly, there is an open standards revolution in all our futures!

... on how you could capitalize on the lower cost of open systems.

Other common migrations

Where would you like to migrate today?

When we talk of IT migration we automatically think of servers. However, all parts of IT can benefit from a combination of lower costs and simplification; that's why we are seeing an accelerating rate of migrations affecting all areas.

Each type of common migration has particular benefits that stand out. Here are some examples:

Database migration

Large complex databases are hungry for two things - scalable performance and availability. While there are many other benefits, these are the focus of many who migrate to a new DBMS.

Storage subsystem migration

Storage capacity has been growing exponentially; but so has storage complexity. As a result, total cost and availability are increasingly concerning IT management. That's why moving to storage networks is one of the most common migrations we have seen recently.

BladeCenter migration

Moving a sprawl of "PC-based" servers to a BladeCenter can yield the full spectrum of benefits from simple cost savings to the total, long-term cost of systems administration. However, two aspects of this type of migration are so obviously spectacular that they often steal the show:

• Physical space reduction

• Collapsing the clutter and complexity of multiple server and network boxes and the associated spaghetti cabling

... on how all types of migrations could improve your future.

TechTip: Linux on Power...32-bit or 64-bit?

By Debi Reidel, Technical Engineer, Datatrend Technologies

Once the decision to port applications to Linux on POWER has been made, you may also consider reviewing opportunities for porting 32-bit applications to 64-bit.

It is important to note that 32-bit applications that do not require 64-bit capabilities should remain 32-bit.

Any porting effort involving a migration to 64-bit should be taken in two steps: First, migrate to the target platform as 32-bit, and only then proceed to 64-bit.

This will eliminate any confusion with identifying issues arising from the platform migration versus an issue associated with the migration to 64-bit.

Applications should be ported to 64-bit, if it would benefit from the following:

• Use of more than 4 GB of virtual address space

• Utilization of physical memory (greater than 4 GB)

• Use of 64-bit size integers

• Use of full 64-bit registers to do efficient 64-bit arithmetic

• Use files larger than 2 GB

An application can remain 32-bit and still run on the 64-bit Linux on POWER kernel without requiring any code changes. IBM Linux on POWER processor-based servers support both 32-bit and 64-bit applications running simultaneously on the 64-bit architecture without any performance degradation between modes.

When converting 32-bit applications to 64-bit applications, two basic issues are likely to arise: Data type inconsistency and interoperation between applications using different data models.

The 64-bit environment uses a different data type model than the 32-bit environment. For Linux on POWER, the ILP32 model is used in the 32-bit environment, while the LP64 is used in the 64-bit environment.

The differences between these two models are the sizes of long and pointer. Therefore, when an application is converted from ILP32 to LP64, fundamental changes in data type occur. Longs and integers are no longer the same size. Pointers and integers are no longer the same size. Also, the size of objects like structs and unions is bigger in the 64-bit environment if they include pointer or long data types. Other issues commonly spawned by these differences are:

• Data truncation

• Pointer assignment

• Data alignment

• Data sharing

For more detailed information on porting from 32-bit to 64-bit, refer to the IBM Redbook "AIX 5L Porting Guide" by clicking here.

Contact us | Visit Datatrend website

All trademarks, registered trademarks and service marks are the property of their respective owners.
IBM, the IBM logo and other referenced IBM products and services are trademarks or registered trademarks of the International Business Machines Corporation in the United States, other countries, or both. All rights reserved.

UNIX is a registered trademark of The Open Group.
Windows is property of Microsoft Corporation.

Brought to you by Datatrend Technologies Inc.

6815 Meadowridge Court, Alpharetta, GA 30005