Whether it's an off-the-shelf application, or one that your internal software developers have written specifically for your business, if a new application is going to appear on the network you need to make sure you know what effect it's going to have.
Hopefully someone from the network team will have been involved in the project from quite an early stage, so that you can point out the obvious - like why it's really not a good idea to write this application to use IPX, when you have an IP-only MPLS WAN, and don't specially want to have to tunnel everything. Or why it might be easier for them to assume that all the clients can broadcast to find the application servers but that's not going to be very efficient over your heavily-routed network.
But even once you've got them heading in a direction that looks like it might actually work, you're going to have to profile the application in a test environment to get a feel for how much traffic, and of what type, you're going to have to cater for. You also need to capture successful transactions so that when it all goes live, and you start having problems, you know how it should work.
There are analysers that offer application and transaction profiling as part of their added functionality, such as Application Expert from Compuware but there's a lot you can do with a standard analyser and a bit of networking knowledge.
You'll need to get a test environment set up so that you can capture all aspects of the various transactions. If the application is going to be run over the WAN (and just because it isn't on day one doesn't mean it won't be later), then ideally get it tested from a remote site (or simulated one) too.
You need to capture all the data, to and from both the client and the server, through all the various parts of the transaction. Don't limit yourself to client-server traffic - there may be DNS queries that you need to know about, or any manner of backend lookups that aren't apparent to the user but add extra traffic on unexpected segments of the network. Is information cached anywhere and, if not, would it be better if it was?
You'll need to timestamp each part of the transaction so that you know what should happen when, relative to other queries. You should end up with, more or less, a flow diagram of how the operation as a whole hangs together. And for each part, you need maximum and average packet sizes, how much actual data is sent, and over what time period. This will let you figure out how much bandwidth you're going to need, once you've extrapolated up to the expected number of users.
Make sure there's no concern over MTU sizes (specifically for the WAN) and look inside the packets to reassure yourself there's nothing too odd. Yes, this takes time, but it's preferable to the panic of trying to troubleshoot blind later. Are there any protocols you typically filter out, or a reliance on broadcast or multicast that you don't currently support?
Try flooding the test network with other traffic and see how the application copes with delays. If multiple servers are needed to complete a transaction, what happens if one can't be reached? What indication do you get on the client screen and what's happening on the sniffer? These are more to help you with future fault finding but it may be the best time you get the chance to pull things apart and see what happens. Things you learn here can be included in the acceptance documentation for the support team.
In the case of a bespoke application, running tests on it as soon as there's a vaguely stable version available is best. Even if you have to repeat the tests several times as the code changes, you stand a better chance of spotting something that doesn't best suit the network and possibly getting it changed at an early stage. Something like a hardcoded IP address or inappropriate packet sizes might slip in and can be changed before it's too late.
If it's a ready-made application, you're going to have to live with it to a large extent, although even here there are tweaks and options that the server and desktop guys can make based on what you see with your analyser that might make everyone's life easier. So give yourself time early enough in the roll-out schedule to be able to influence how the application is deployed.
And particularly if this application has to go over your WAN, unless you have a lot of unused bandwidth, make sure that you give yourself time to order circuit upgrades if you need them, and get any reconfiguration done if you need to change or introduce QoS settings, if this is a particularly time-sensitive application. Make sure too that any pilot deployment includes users at remote sites, not just a group of head office users connected to a Gigabit backbone.
Apart from making sure that the application will actually work in your environment, and won't add gigabits of traffic because it's been written badly, profiling gives you the perfect opportunity to get to know the application while it's behaving itself. Document how it should work and you'll make your life that much easier when it doesn't.