The simple answer is yes!

I have gone from a 32bit Redhat 3.1 Dell Poweredge 1850 environment to a newer Dell R710 Server  running Redhat 5.6 and then virtualized onto VMWare when It suffered and array failure. Going 64bit is good because the 4GB memory limit is removed so you can throw more RAM at your Tomcat Instances.

Besides the base eB2SP9 of MFG/Pro running on Progress 9.1e we have the QPS, QXTend, TrM, AIM modules and the .net Interface (which runs on Progress 10.1B).

DISCLAIMER: This is possibly/probably not a QAD supported configuration. But has been working for me for over a year.

I have also done it with an IP Address and Hostname change too.

There are a a few of challenges:

Database connections may fail because newer versions of /etc/services have more ports reserved and progress won't bind to a port reserved in /etc/services. Therefore you may need to shift your progress db port ranges around

Telnet server by default has too few allowed `per_source` connections

#/etc/xinetd.d/telnet
service telnet
{
        disable = no
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/sbin/in.telnetd
        log_on_failure  += USERID
        #add high per_source
        per_source      = 1000
}

When doing server rename the embedded configuration in some MFG databases needs to be updated.

Samba should be upgraded to the latest available 3.6.6-0.129.el5 which equates to the samba3x-* packages. This stops some core dumps I noticed In the logs when using the previous version 3.0.33-3.28.el5 (samba-* rpms)

Dependency problems missing libraries

You may need to scan all your logs to find missing library errors and rectify.

Error:
Could not open Dynamic Library: /u4/app/dlc/91e/lib/libicuuc-psc.so (8013)
DLL Error : libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory (8014)

To fix (for x64 RH5.5):
Make sure compat-libstdc++-296-2.96-138.i386.rpm which is the default compat-libstdc++-296 on the redhat 5.5 install DVD is installed then

cd /usr/lib
ln -sf libstdc++-3-libc6.2-2-2.10.0.so libstdc++-libc6.1-1.so.2

#It should look like this:
ls -al /usr/lib/libstdc++-*
-rwxr-xr-x 1 root root 259532 Aug 22 2006 /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
lrwxrwxrwx 1 root root 31 Feb 16 11:29 /usr/lib/libstdc++-libc6.1-1.so.2 -> libstdc++-3-libc6.2-2-2.10.0.so
lrwxrwxrwx 1 root root 31 Feb 16 11:22 /usr/lib/libstdc++-libc6.2-2.so.3 -> libstdc++-3-libc6.2-2-2.10.0.so

There are other challenges to doing a 32bit to 64bit uplift but the above hits the high points.