Well, without knowing a lot more details, I think the best I can do is offer some points, in no particular order:

1. Make sure everyone knows what the system MUST do, as opposed to what everyone WANTS it to do

2. Spec software to meet the needs, and the wants where achievable

3. Spec the hardware/OS platform(s) to support the software and the required level of availability

4. Is there concern that existing platforms (older Unix, FP/Unix, possibly old hardware) are not supported, or soon will not be? i.e. are they sustainable?

5. Is there concern that people with skills to support the existing platforms may retire or otherwise be difficult to replace? Are existing people open/able to learning new platforms/skills if required?

6. What are the constraints, if any? For example, maybe you want to select a platform that requires replacement of the handhelds. If you have 500 handhelds @ 2K each, you're talking a million bucks, you might get some resistance about that

7. At the client, are there people with the commitment and authority to implement major changes, if that's what you recommend? In my early days consulting, sometimes I'd get called in by junior people to evaluate existing systems and make recommendations. It would turn out that really all the client wanted was justification for continuing to do things the way they always did them. These days, I deal only with principals, and I have a heart-to-heart with them so I know it won't just be an exercise in futility.

8. Are users amenable to using new systems, if required? How will the client handle training and temporary loss of productivity during the switch?

9. If you decide to use new platforms and software, probably the only way you can prove to the client that it is as reliable as the old (and not affect the current system during testing) is to run it in parallel with the old for some period of time. Would the client be agreeable to building up a completely separate system, and implementing any required synchronization between old and new?

10. Individual *n?x servers are more available than Windows, in many cases updates or patches can be applied without requiring a restart. If you are currently using clustered servers (physical or virtual) that may not be as much of an issue, they can usually be updated (and restarted if necessary) one at a time so availability is unaffected

11. Windows platforms are much more susceptible to malware than *n?x

12. If you are contemplating setting up customer access via the Web (public Internet), you will need special infrastructure and skills that the client may not currently have because they don't need them

13. For maximum reliability/availability and flexibility/accessibility, you will probably want data stored in a big-name SQL RDBMS. If you need HA, vendors will probably want to provide a hardware/software combination such as Oracle on Sun, DB2 on IBM, or SQL Server on Dell/HP.

14. Your RDBMS choice may come with a preferred dev platform. For example, Oracle may prefer Java, SQL Server may prefer .Net etc.

15. Software reliability is hard to measure. What are the current languages/platforms? What are current software development practices, and the skill levels of the people involved? For example, if it's currently C/C++, by good people with good processes, that will be hard to match.

>The back end is an older version of Unix with data in a few formats, a significant one being FP unix.
>
>
>>Not sure what the back end is, but it should be possible to create a web site for their customers to view things without trashing the entire system. I agree with Al, if it ain't broke don't fix it.
>>
>>>The biggest potential gain is that they could create web apps that would allow their customers to login and perform various tasks. Currently the customers call and say "hey, i htink you made an error last week, could you check? Is my blah blah blah still in location blah?"
>>>
>>>The customers are in general scattered, numerous, and would have access only to a desktop browser for connectivity.
>>>
>>>>>I am interested in opinions on the following scenario, which I have to reply to and advise a client.
>>>>>
>>>>>First, a disclaimer: I know that absolutely everything can be done in absolutely every platform. If you wish to evangelize for a platform, this is not for you. I need to provide info based on the idea of offering solutions to problems that will best serve the client.
>>>>>
>>>>>The current system has handheld devices in the field. These devices run a terminal emulator and talk to a Unix server. There are disparate locations where groups of people with these handhelds do the equivalent of taking complex inventory by answering a series of questions on a text-based interface in the term emulator, and the results are stored in a database on the corporate Unix server.
>>>>>
>>>>>In addition, at each regional location (where the handheld users are) there are numerous users running reports and updating the data, either the actual data from the handhelds or related data.
>>>>>
>>>>>Then there are users at corporate mostly running reports.
>>>>>
>>>>>Then system has been running since 1999 with 100% uptime. All user processes are accessed 24x7 and it is mission critical that 24x7 access for reporting and especially data entry from handhelds be available. 99.999% is not good enough. They have government contracts and there simply can never be downtime -- ever, ever, ever, ever, no matter what. It might be surprising, but the data is in a variety of formats -- old FP unix tables.
>>>>>
>>>>>The system works great, but of couse allows for no modern interfaces. Adding reports or features is painstaking, and a web user interface so customers could enter or reviw some data themselves is not practical. And they are struck using forever an old version of Unix because of the FP tables.
>>>>>
>>>>>Now I have been asked to answer the following questions. Obviously I do not expect some of these to be answerable here, but to give you the picture:
>>>>>
>>>>>1. Should they move to a more modern platform to enable web interfaces, or should they keep their old system becauise of its rock solid reliabilty?
>>>>>
>>>>>2. If they should move to a modern platform:
>>>>>
>>>>> a. what should it be?
>>>>> b.how can we ensure the same level of software reliability? Don't GUI's and wen and the like introduce an element of uncertainty that we avoid with our text system?
>>>>> c. what would be the best data storage option?
>>>>> d. what development platform would make the most sense for backoffice, in-office, and handheld-field use?
>>>>> e. if we use anything windows based in such a system, are we introducing reliability risks?
>>>>> f. how long and how expensive to do?
>>>>>
>>>>>3. if they should keep their current system because of its relability:
>>>>> a. is there some way we can get web capabltities without changing the text-handheld system or the data storage?
>>>>>
>>>>>I have formed my opinions, but I wish to hear what some of the experienced consultants here have to say.
>>>>
>>>>I'm a relatively experienced programmer, but NOT an experienced consultant. I'll offer an opinion anyway.
>>>>
>>>>How often do they need to add reports and features? How much easier/faster would it be in the new environment?
>>>>Are the users complaining that the current system is too slow and/or clumsy to use?
>>>>
>>>>What additional benefits do they gain from moving?
>>>>
>>>>My guess is not much and if the current system is working satisfactorially (even if not optimally) it won't be worth the pain and effort of moving.