I spent last weekend building a new system for a client.
The old (current production) system is an Acer Altos G700 with 512mb memory, dual P4 2.4ghz processors, dual channel LSI RAID controller with 4 72gb Seagate disks. This system runs SCO 5.0.7 with MPX and all the patches applied.
The test system is a white box based on an ASUS motherboard with 4gb of memory, dual P4 2.8ghz processors dual channel Adaptec RAID controller with 2 36gb Seagate disks and 2 72gb Seagate disks.
Installing 6.0.0 took about an hour, then another hour to install Maintenance Pack 2 and the balance of the patches.
The old system uses Visionfs as its SMB server where the new system uses Samba. That required changing the printer drivers and the smb.conf file for the shares.
The userids and passwords were copied using 'ap'.
I used Microlite Edge to restore the non root file systems from the backup tapes.
The client application written in Foxpro uses about a dozen databases totalling about 3gb of data.
There is a batch job that runs every night to generate reports and work files.
On the old system this job takes about 3 hours, on the new system 20 minutes.

You mentioned is right and i also experienced it with even 5.0.7 and with 6.0.0 also. Here in my Organisation we use foxbase+ and lot of processes crunchy applications are run daily. Wonderfully SCO 5.0.7 utilised my new Xeon based hardware and the time for processes reduced drastically!!

I would like to get one doubt as you mentioned abt Foxpro files running in SCO Unix. My foxbase+ files(compatible with foxpro) are working fine in 5.0.7 but failed to identify the index files .idx in 6.0.0.

Could you help me to identify the problem with that? Or if your client is working with foxpro files in SCO how is it possible??

My client uses Microsoft Foxpro version 2.6 for Unix.
Try creating a small database, and creating an index, then see if the index file exists, and if it has a .idx or .ndx extension.
If you cannot create an index file, then try creating an EAFS partition instead of the default vxfs.

I am planning to move a Foxpro 2.6 for unix application from a SCO 5.0.3 system to a SCO 6.0 system. What problems should I expect, and would 5.0.7 be a better choice?

Since 5.0.5 or 5.0.6 the original Microsoft diskette installation procedure does not work. The easiest solution is to tar /usr/lib/foxpro and /usr/bin/fox* from your existing system and then restore the tar file on the new system (either 5.0.7 or 6.0.0).
If you are planning a fresh install anyway, there is little difference in the amount of effort required for either upgrade.
The certified hardware list might become the deciding factor.