(Note: this article appeared on c|net’s News.com site back in 1996. If you would like to read more, here is a series of columns that I wrote about turning off Edison Electric Institute’s IBM mainframe a year earlier.

While I was at Interop last week, I met several people who were in charge of building Intranets. They weren’t happy campers, mainly because they were told to move data off their mainframes and on to these new Intranets. The more we talked, the more I shared their pain and realized that this isn’t going to be as easy as all the pundits say. In fact, it could well become a real nightmare. Why? Several reasons:

First off, those mainframes have a nice security system that will be hard to reproduce on the Intranet, at least without a lot of planning and forethought. One choice is to make use of your network file server’s security system, but that turns out to be a problem. File-based security either has too much granularity (do I have to set file access rights for each file or each directory?) or too little (I want to set rights for workgroups that may or may not be on the same server). Another choice is to use the database or web server as the security system: again, it is hard to get the right set of access rights with many of these products, particularly if your workgroup spans departments, cities, and servers.

Second, the tools for doing this task are, well, they suck. Many of them are just coming out with version 1.0 (not a good sign of a maturing market), or else they don’t handle really large quantities of data, or else they require a great deal of programming expertise or specialized knowledge. There are a few products that offer some hope, and I’ll get to that in a moment.

Third, many corporations have the wrong mix of skills to build Intranets. And to make matters worse, many companies have begun  retraining their programmers to do C++, thinking that was the right path. One IS manager told me: “I’ve got plenty of COBOL programmers. We got finished telling them that they have to learn this client/server stuff. They don’t want to learn HTML and the web on top of that.”  

Finally, the vendor community has been motivated to make money through consulting services, rather than deliver software to help with Intranet migration. You would think if we have all this data sitting in a nice CICS dataset up on my mainframe there would be plenty of vendors banging at our doors by now to help move it to someplace like a nice Unix or NT Oracle server. And there are — they just want us to pay tons of cash for consulting and systems planning to make the move. 

So what to do? Here are some suggestions:

If you can keep your data on the mainframe a little while longer, then look at products like Simware’s Salvo and Attachmate’s Emissary Host Publishing System. Both allow you to design web front ends to 3270 screens, and can get you used to designing better-looking interfaces without having to muck with where you have to move your database. This approach may not save you much in money, but it may make the transition from the world of the mainframe to the Intranet more pleasant.

If you got to move your data, think carefully about what will be your first project. Don’t pick the most used, mission-critical data first: that kind of visibility you don’t need. Find something that is smaller, less central to your corporate business as a pilot project. That way if you fail, you might still have a job. I recommend that you get yourself a copy of O’Reilly’s WebSite Pro and experiment with the bundled copy of Allaire’s Cold Fusion that comes with the product: you have everything here you need to put together a small database with web front-end links. WebSite Pro also has one of the best documented manuals to walk you through the process as well.

Once you have tried this, then it is time to pick your database server that will become your mainframe-replacement. If you are using Notes, consider that first. If you aren’t yet into Notes then I would start with a more traditional server such as Oracle or Sybase.  Both of these databases have good methods of manipulating large data sets, are reliable and dependable. Which one to pick? It doesn’t really matter, despite what the vendors will tell you. Find someone on your staff that has used one of them and set a standard.

Your last step will be to decide whether you want to develop your front end in a client/server proprietary tool such as PowerBuilder.

It won’t be easy to make this move. But the time is ripe to get started and you should at least plan your strategy.