Article: Overview of Migration Issues for cc:Mail Customers

A significant number of Lotus cc:Mail customers are evaluating migration alternatives for several reasons. Lotus and its competitors have suggested that somewhere between none and all cc:Mail customers will migrate in the next 3 years. While experts disagree about what percentage of cc:Mail customers will migrate, it is certain that the majority of cc:Mail customers will either upgrade or migrate before the year 2000. The majority of cc:Mail systems are still today running database version 6 (DB6) which is not Year 2000-compliant. These customers are either upgrading to cc:Mail R6 and above (database version 8 or DB8) or migrating from cc:Mail to other messaging platforms such as Domino.

All of the alternatives to traditional file-sharing cc:Mail, including the cc:Mail R8 Internet standards-based server products (SMTP, IMAP4, POP3, LDAP, and HTTP) are client/server solutions. In traditional cc:Mail implementations, client applications or User Agents concurrently accessed cc:Mail database files stored on file servers. The most popular file server Network Operating System for cc:Mail has always been Novell NetWare and this remains true today. This is significant because it means that customers looking at migration to client/server messaging do not typically have in place the makings of a client/server messaging infrastructure.

In any case, the days when e-mail was a departmental workgroup solution running on local file servers, i.e., traditional cc:Mail systems, are simply gone. E-mail today is a global, business-critical application. The cost of down time, for example, has increased along with the general dependence on e-mail in most businesses. This is especially true where e-mail has moved into core business functions such as sales, order processing, and inter-enterprise collaboration through extranets. At the same time, the rapid influx of fast-moving open Internet standards-based messaging technologies into traditional, proprietary systems and the introduction of natively standards-based messaging solutions such as Netscape messaging have done anything but simplify the messaging landscape despite the fact that all of these products will eventually interoperate seamlessly thanks to Internet messaging standards. The key word here is "eventually" (for example, while every vendor now claims LDAP support, only one supports LDAP v3 replication).

To make matters worse proprietary messaging vendors have alternately tried to embrace and compete with Internet standards-based messaging technologies. While on the one hand every vendor has jumped on the Internet standards bandwagon at least paying lip service to Internet messaging standards, vendors of traditional, proprietary messaging technologies have defined their own 'standard', Business Quality Messaging (BQM). BQM is an incredibly vague set of guidelines that allow vendors of traditional proprietary messaging technologies to sell more or less what they already have under a new label so long as they implement a given set of reliability-related features the most important of which is that they are not in any Internet messaging RFC. Nonetheless, BQM remains a wallflower at the messaging dance.

As if this were not enough to give CIOs and IT architects headaches, messaging is just not what it used to be. These days, messaging customers aren't merely shopping for a messaging system, they are shopping for a next-generation architecture that integrates a variety of IT services including messaging, calendaring and scheduling, electronic forms and workflow, Intranet applications, extranet technology, Internet standards, and the World Wide Web into a common, usually standards-based, infrastructure. Every vendor claims to have all of these things but none of them actually do. Lotus cc:Mail has stepped up to bat alongside the newer players sporting the full range of open Internet standards-based messaging technologies, at least in spirit if not in fully corporeal form.

Customers are looking for integrated infrastructures capable of hosting a variety of applications and of providing a variety of services throughout the corporate enterprise. To some this means upgrading to Domino for a one-size-fits-all solution. To others this means mixing and matching products from different vendors that share common standards. For example, some cc:Mail customers are deploying Netscape Communicator or Microsoft Outlook but preserving a cc:Mail back-end by running the R8 POP3 and IMAP4 servers (once deployed standards-based clients can be leveraged for migration).

>From a technological perspective, traditional file server-based IT services have been loosing ground to client/server solutions for several years. The majority of file servers deployed today will be replaced by application servers of various kinds. In general, client/server systems are more manageable, more scaleable, more open, more reliable, and able to support more users per server than file server-based technologies. While several hundred cc:Mail users can be supported with one DB8 post office on one file server, for example, several thousand can be supported by a single client/server messaging server.

One of the main stumbling blocks in migrating to a client/server messaging system is the cost of infrastructure. Although many IT managers find the idea of fewer, centrally-managed servers attractive their ambitions often end in sticker shock. The most basic issue is that a highly-centralized client/server infrastructure requires server and network resources beyond the capacity of the installed base of most file server-oriented systems.

Solutions such as the Notes/Domino NLM for NetWare servers do not solve this problem because existing server and network capacities are typically not up to the task of supporting a Domino server infrastructure overlaid on existing networks and server hardware. Further, the back-end of the system is only one piece of the puzzle. In practical terms, crossing the chasm between file servers and client/server systems means not only network upgrades and new server hardware but also workstation upgrades. While a product like cc:Mail R6 can run comfortably on a 50MHz '486 CPU in 16MB of RAM, newer client applications like cc:Mail R8, Notes 4.x, Microsoft Outlook, and Netscape Communicator Pro have a footprint that would make a sasquatch jealous. Getting back to cc:Mail, the cc:Mail Java client delivers a complete cross-platform solution but customers already struggling with the limitations of workstation hardware won't see much benefit from it. Eventually we'll have Java chips integrated into every hardware platform, including PDAs and possibly toasters, but for now Java is no solution to workstation woes.

Unfortunately, the promise of thin clients and powerful servers is not a reality today. Instead, we have ever fatter clients, a rapidly proliferating plethora of middleware, and server infrastructures that often do not deliver in the performance and scalability departments. Even the web browser has become a sluggish, RAM-gobbling Java Virtual Machine with a 30MB footprint on disk. In any case, messaging systems are far from exempt when it comes to the state of the three-tiered architecture that remains the guiding vision of most CIOs and IT architects around the world.

Of course the IT strategy and infrastructure considerations are not the only ones and they are not the only contributors to the overall cost of a new messaging system. In addition to the obvious costs of hardware, software, and training for IT staff and end-users, a tremendous amount of technical expertise, project management, enterprise-wide coordination, and sheer labor is involved in getting from one e-mail system to another. Not to mention yet another can of worms: migration and coexistence tools.

Several vendors offer free migration tools to round out their competitive offering but for the most part customers are getting what they are paying for. What use, for example, is a migration tool that requires local workstation installation on 5000 workstations, then has to be uninstalled when the job is done? Stranger things have happened. One migration tool was written entirely in Java which seemed like a cutting-edge idea until it became clear that every workstation would have to have a runtime Java environment installed including components from the Java SDK.

Fortunately for everyone, a variety of 3rd party migration tools are appearing on the market but this is not a complete solution. Customers need not only tools but expertise and with so many permutations of migration variables customers are hard-pressed to find people skilled in the multiple e-mail systems involved in their particular migration, not to mention with the related issues and tools. Nonetheless, customers cannot be expected to get through the migration process unassisted and messaging vendors are not providing much help. This is not simply because of weak tools but because migration is in a gray zone between sales and consulting where sales want to give away migration tools and services but where consulting doesn't do anything free. Here too, 3rd party messaging integrators experienced in migrations can help.

So what does all this mean to the average cc:Mail customer? Well, it means that staying where you are is the least confusing and, in the short-term, the least costly alternative. Unfortunately, this is simply not an option for a substantial number of cc:Mail customers, particularly the larger concerns that have outgrown file server technology and where infrastructure is, therefore, a key consideration.

Despite all the post-Lotusphere 98 fuss about Lotus' increasingly limited support for the cc:Mail product line some customers are planning to retain their cc:Mail infrastructure well into the 21st century. In most cases, this will means deploying standards-based technologies on the client side which viable up to a point but doesn't allow the level of centralization (and doesn't provide the degree of standards support) available in other solutions. Nonetheless, deploying standards-based technologies on cc:Mail R8 and standards-based clients can be an important preparatory step before cutting over the back-end to a new client/server system. The only fly in the ointment is that R8 (and Domino on the Intel platform, and Exchange) is quite NT centric which may not be completely agreeable with the many NetWare shops still running cc:Mail.

To sum up, although there is tremendous momentum and increasing 3rd-party support (ISVs and messaging integrators) behind migration to Domino, Exchange, and Netscape messaging, there remains that other principal of physics that an object at rest tends to stay at rest. So while a large number of cc:Mail customers are either migrating or planning to migrate, others will hold off, potentially for as long as Lotus continues to provide adequate support for cc:Mail.