Recently, as a part of my server consolidation strategy, I came across a server and a business application that had been flying below the radar for several years. It had avoided detection because it was a small team of 12 people supporting a niche market that was tiny in relation to our main business. It bubbled to the surface because of my teams goal to achieve 100 percent compliance on server and desktop patching, not to mention my goal to eliminate all servers at remote locations.
The Challenge to Overcome
Further investigation revealed that the application was simply a Paradox Relational Data Base which was administered by one of the sales folks at the remote location. To compound matters, the database and the server were, to put it kindly, vintage.
This prevented my team from moving the obsolete desktops at that location from Windows 98 to our minimum standard of Windows 2000 or XP. Moreover, server was a clone that was living on borrowed time.
Essentially, I had three challenges to overcome. The first was to get the business folks out of engaging in IT. Secondly, we had to switch to current database software that would be work on Windows 2000 and XP. Last but not least, get rid of that boat anchor of a server, adding another notch to my server reduction strategy.
Consider the Needs of the Business
My immediate reaction was to remedy this situation by forcing the business unit to leverage existing back office systems rather than continually supporting one-off business applications at a remote location. However, after visiting with the business unit executive and our systems programming team, we all agreed that the time and effort required to integrate this operations systems into the fold would cost more in the long run than to support the it as one-off system.
Nonetheless, I did not want to continue to maintain a server at a remote location. Remote servers present all kinds of challenges such as backups, patching, disaster recovery and routine support to mention a few. As a result, I pulled my network and desktop services team together and challenged them to remediate the issue.
The only requirement I put forth to the team was that the solution to this problem could not disrupt the business units operations and that it would blend well with our existing infrastructure and overall strategic plans.
The desktop services team completed the first phase, which meant determining what to do about the old Paradox Data Base. After working with Paradox support, my team quickly came to the conclusion that a current version of Paradox would solve the problem.
Now that we had the database issue out of the way, the server team took a look at the database, concurrent transactions, and storage requirements, which they used to determine the server specs. However, during this process my senior server engineer recommended that we use our existing assets rather than introduce a new server, be it local or remote.
Specifically, why not move the database to our Net Appliance NAS and publish the Paradox Application on our Citrix Farm? Citrix enables users at remote location to access centrally located applications similar to the way one would access LAN-attached applications.
Since the user community was accustomed to accessing a LAN-connected server, it was essential to not make significant changes to their business processes in order to minimize training and maintain employee morale. Any change can have a negative impact to morale and subsequently productivity if not managed right. Citrix met this entire criterion.
Once my team had thoroughly tested accessing the database remotely via Citrix, the business unit manager and I settled on a hot cut-over date.
The plan of attack was simple. My Server Engineer would come in early in the A.M. and move the current Data Base from the remote server to the NAS located in the corporate data center. At this same time, one of my senior PC service technicians would be on site to exchange the obsolete PCs with new Dell PCs running XP.
When the sales folks come in, they would immediately start accessing the corporate NAS via Citrix. To ensure a smooth transition, the PC technician would stay on-site for a couple of days to resolve any technical or user questions which might crop up.
On D-Day the database was moved and the users came up on their new PCs without a hitch. The users acclimated quickly and were able to access and manipulate the data they needed via Citrix and the new Paradox software.
On occasion, one of the power users would experience latency when making significant updates to the database. This was determined to be a bandwidth issue as the remote site only had a 384 KB Covad Tele-Extend broadband VPN connection to the data center. I made a quick call to Go Remote Internet Communications, managers of my broadband network, briefed them on the situation and requested that the connection speed be upgraded to T1.5. Much to my surprise Go Remote and Covad completed the changes in less than 24 hours.
Empower Your Team and Challenge Your Vendors
In many cases one can resolve what appears to be a major issue by just taking a close look at your existing infrastructure and ensuring that you are leveraging those assets to the fullest extent.
The people matter too. The only requirements are a top-notch technical team and a management philosophy that gives them a job and lets them do it. I have an outstanding engineering and support team, so I knew whatever plan they developed with would be both cost effective and reliable.
And in my case, business partners that react with a sense of urgency always helps.
This article originally appeared on Enterprise IT Planet.com.