Nmedia - Fotolia

Problem solve Get help with specific problems with your technologies, process and projects.

Can you verify software compatibility on IT systems?

If you're thinking about deploying an application software package, how do you know if it is compatible with your particular systems and hardware?

Every IT deployment is different, so you can never be guaranteed application software packages will work on your infrastructure.

Several strategies will mitigate the risks of deploying new software. The approach you choose depends on the time to invest in software-compatibility testing and the potential detrimental effects on users and the business if something goes wrong with the application.

Read and check the install requirements in the product's associated documentation first. Run through the details of your existing environment and planned application software deployment with an engineer from the product vendor to find and review any concerns. They may also share install tips or tricks that aren't in the official documentation.

Another good method is to find someone else -- via articles, blogs, user forums -- who has deployed the same application software package and learn from their experience. Find out how they installed the software and how it's working. A quick chat with a pro could save you days or weeks of work, or steer you away from a product with poor vendor support.

The most thorough way to ensure application software packages will work on your infrastructure is by testing. But even then, you can't be 100% sure everything will work. Test software compatibility at both the infrastructure and user ends. If you have the resources, run a full simulation before rebuilding or migrating across to production.

User acceptance testing (UAT) is the best method, often associated with piloting a new application or major upgrade. UAT will highlight any fundamental issues with the product or with the hosting infrastructure. The process should give users, the business and the IT team confidence to deploy a systems software tool or application software package to production.

About the author:

Adam Fowler is IT operations manager at a law firm in Australia. He's worked in IT for over a decade, including responsibilities in systems, infrastructure and operational service. He blogs about all things IT at http://www.adamfowlerit.com/.

Dig Deeper on Configuration Management and DevOps

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Would another user's negative experience steer you away from using a product?
It would, although I would take any opinion with a grain of salt, because situations in different companies are very different. I wouldn't want to completely dismiss something just because one company didn't have the resources or expertise to make it work. 
Absolutely, but a lot depends on who that person is, what I thought about what they said, a lot would depend on what they actually did say.  

For example if this was an issue with security, and it was a product which I felt strongly about wanting to know the product took security seriously, yes it would.

If it was something more cosmetic, it would depend a lot on what the issue is.  

I know I read a lot more negative reviews than the positive ones, and if an application has a trial or demo, I might still give it a try, but there are certain types of product, if I learned certain things, I'd not even give the application a chance.  is that wrong?  Maybe, but its the job of the producers to get the attention, and assure customers that what they are buying is in fact what they need.
It would depend on the user and if there were more than one user with a negative review. The product may not have met their needs and that is the reason for their negative comments. 
Depends a lot on how close to the experience the negative review would be to the one I'm trying to implement or solve. If the particular user is not dealing with the issues I'm focusing on, or it's a tiny portion of what I would interact with, then I might put little stock in the negative review. The closer to my own pain points, the more likely I'll be to pay attention.
Maybe a particular version of the product. Some companies respond to feedback fairly quickly and improve the product. In this case, "negative experience" would be a positive factor.
Good point, agareev. I always try to wait a version or two before trying out a new product for this reason. 
One user...? Probably not. Multiples would certainly give me pause. At least long enough to see who was unhappy and why. I'm for more interested in the wide impact than someone's personal problems or lack of the proper skillset. 
Good points everyone and agreed - very contextual, and as always each scenario is going to be a little different.
In most cases, the only way to know for sure if a solution will work is to put it into an environment as close to what you will be running in production and check for yourself. To this end a virtual sandbox is a an imperative. For that matter, I would recommend individuals do the same thing in a virtual environment before committing themselves and their machine's bare metal to an application. If it doesn't work well in my virtual space, with all of its complexity abstracted away, it's a pretty god bet the hardware I use in the real world will likely not cope well, either. The converse is not necessarily the case, but I have higher confidence it will work if it survives an outing in my sandbox.
That's why there's such thing as UAT environment. Not only new software, updates and patches to the existing software are to be tried first. And quite often a particular patch is found causing problems.
Sometimes this pre-rollout testing is done by IT Services team alone, sometimes in collaboration with internal QA departments.