There were a few skeptics. Some reacted out of self-interest, fearing the loss of technology upon which they had built careers. Others were experienced technologists who had taken part in past migrations and understood that paradigm shifts never occur as quickly as analysts predict.

We moved ahead in spite of the warnings, determined to make progress on four fronts. First, we had to build a scalable network infrastructure that would serve as the critical middleware foundation for client/ server applications. Second, we needed to implement a new non-mainframe back-end systems environment that would be scalable and reliable. Third, we had to ensure that an adequate desktop computing environment, with the associated support services, was in place. Finally, we had to find some applications.

Take the Network Out of the Picture Early in the process, the most commonly expressed concern related to the need for a pervasive, reliable, high-performance network infrastructure. Without it, deployment of client/ server replacements for our legacy systems would be impossible. Here, we caught a few breaks. We had a fairly well-developed structured wiring system in place and we had decided in 1991 to phase out all of our older networks and standardize on 10BASE-T Ethernet. It took some time and effort to rip out all that old Arcnet, token ring, LocalTalk and terminal server equipment, but we eventually got it done. We focused more attention on proactive management and on-site sparing of all critical components, and we took the time to document the network thoroughly.

For the most part, we managed to stay one step ahead of the capacity curve, though we made it clear early on that the network was not designed to support real-time applications. At times, the exponential growth in the number of nodes resulted in some performance concerns on our busiest networks, but by then we were experienced at segmenting LANs using routers. Later, we deployed switching hardware and VLAN technology to ensure that the network was not the source of any performance bottlenecks.

The story was a little different on the systems side as we attempted to scale the environment. We found it relatively easy to provide robust file and print services using NetWare as a platform. Better price/performance for Intel hardware and SCSI-based disk subsystems let us improve service without spending a fortune. Implementing NDS further hiked our administrative efficiency while creating an environment that let us decentralize some services without sacrificing integration.

On the application-server front, the road was a little tougher. Our initial efforts to move academic time-sharing users off our IBM 3090 and VAX/VMS systems and onto Unix were thwarted by instability in early versions of Sun's Solaris. In retrospect, we should have known better, but we violated a cardinal rule: Avoid the .0 release at all costs. The 3090 and the VAX systems eventually went away, though it's only recently that we've made good on the promise of better performance at a lower cost.

Our experience with Solaris forced us to consider alternatives for our database servers; we settled on IBM's AIX as a back-end platform for our business applications. We've been relatively pleased with IBM hardware and software, but our inability to standardize on one Unix platform means higher cost and somewhat fragmented administration.

Conquering the Desktop Given our past dependence on host-based systems, we faced monumental challenges in replacing 3270 and VT-100 terminals with desktop devices. Initially, the per-seat costs were quite high and the life cycle of 386- and 486-class machines was alarmingly short. Plus, we had a substantial installed base of Macintosh computers and loyalists singing their praises. Nobody fully grasped the cost for the hardware, let alone the cost of administering networked desktop devices.

While things are still a little chaotic, we made real strides over time. We moved aggressively to standardize on Windows95 and developed a standardized network-oriented desktop environment with server-based delivery of most applications and automated installation of others. We bit the bullet and announced we could not guarantee support for Mac clients in our business application environment. And we beefed up support and training offerings and leveraged central resources to add departmental computing and network administrator positions.

It's the Applications, Dummy In the end, it's all a waste of time if you don't have the applications. It's been a rocky road in that regard. On the plus side, once we made the decision to eliminate some central host systems and people realized that we weren't bluffing, they found ways to migrate many smaller applications to desktop and departmental systems. Most of these were far superior to their mainframe counterparts. We also off-loaded a number of business applications to robust client/server systems, and these migrations have been well received.

But our bread-and-butter business applications--human resources, payroll, student records, financials and facilities management--have been much more challenging, mainly because of the commercial offerings' immaturity and technical complexity. Software development partners have folded, deadlines have slipped and costs have soared. While our goal of beating the Y2K problem by replacing rather than rewriting legacy applications was laudable, delays have forced us to make tactical investments in Y2K repairs. The pain has been real.

Next month, I'll offer some explicit advice, based on our five years' experience, on what to expect and what to avoid, both technically and politically, in your client/server transition.

Send your comments on this column to Dave Molta at dmolta@nwc.com.