Best practice to depoly a MS-DOS application over an MPLS WAN

What does this application do? Is it a game, a bank wire transfer application, a database which holds the nuclear launch codes?

Who uses your network? Is your WAN open to the public, used to host the DEFCON hacking convention, or are there a bunch of poorly paid accountants using it?

Your network architecture: Do you have a firewall, perform some network monitoring, or perhaps require users to login to get access?

So let me get this straight, you are moving FROM a .net/oracle solution to a DOS-based solution? Interesting. Be that as it may, let's begin:

Security: Validating the security controls of an application like this is not all that difficult. The key is to understand what threats you are defending against and what assets you are protecting.

Some of the questions I would ask would be:
a) what are the real risks/costs of a system compromise? Downtime, theft of company data, financial fraud?
b) what/who are you defending against?
c) what authentication methods are being used?
d) Are the features and capabilities related to authentication something that is off-the-shelf, or something your programmers wrote?
e) database security is the same regardless of platform, it's mostly a matter of using a hardening checklist, like you would with any server or application. And you make sure you are logging what is important, obviously.

Performance:
In the past, I've done a lot of work in this area.
The best approach, if you have the time/money, is to do some network simulation/modeling using the QA/Test envionment for the application.

In the past, I've used hardware network latency simulators to give you the 'magic number' which is the most latency the application and/or users will tolerate. So, for example, if you setup a test lab with ten simulated users, using a testing tool like Microfocus QA Load, you start firing off transactions, then start cranking the latency up and up to see where things get nasty.

At the same time, using tool such as WireShark, you can get some understanding of how the application uses (or misuses) the network. By doing network protocol analysis, you answer the questions "what the network does to the app, and what the app does to the network". This testing will show you some flaws, such as unencrypted passwords, or maybe stupid stuff like apps doing SQL queries over the network.

Once you have a good idea of the amount of latency the app will tolerate, and the amount of bandwidth it uses, then you extrapolate that data against your network design.

For example, I worked once on base-lining the performance for an ERP system. The end users were vehicle-mounted (forklift) users in France, and the SAP database queries had to hit a database in the US. With some testing, we determined that the app simply would not work as-written, as the best we could do on undersea fiber was around 90-110ms, regardless of system load. So the developers had to make some changes to create local data stores. Using the latency simulator in the test lab, we were able to validate that the revised app could not only tolerate more than 110 ms of latency, but it could really go off-line and recover.

So really, is what you're looking at simply one huge Btrieve database?

Good old Btrieve; I worked for a company which used Btrieve for it's email system; over 100K people, all in a big flat file. This was back in the early 90s, before Notes and Outlook were scalable enough for a large enterprise.

I hate to sound cynical, but Citrix is a way to bolt-on performance and security to an app with performance and security issues. To me that's a red-flag that the core system architecture is not ideal. Citrix is a way to make an application that won't work as a client-server app, walk and talk like a client-server app.

I assume that you are not the one who selected this, but the one tasked with making it work?

http://en.wikipedia.org/wiki/Btrieve

this wouldn't happen to be an order-picking system for storage carousels and RF terminals?

I parted ways with a supplier of one of those systems, originally written in DOS, then changed to "run on Windows" (in a DOS box)...

He used Btrieve 6.x database because he had bought an unlimited engine distribution license for that version, and never wanted to spend the money for a dbe. It was really ridiculous, because the software sold for over $20K/station, and all he needed to do was specify what database engine the customer needed, and tell the customer to buy the seats. (MS-SQL would have been an obvious choice...)

But he wanted ALL of the money, and 21st-century purchasers were being sold 1980's technology as new.

I walked away.