Table of contents

Introduction

First and foremost, this is not a rant.

As a consultant, many of my customers use third-party software. Just about every business does. This is nothing new. I recently went through an upgrade, and I want to share some details to show why you shouldn’t just throw your hands up. Don’t be afraid to troubleshoot issues!

A Little Background

One thing I learned early in my career in IT was to always troubleshoot and verify the basics before escalating or asking for help. Looking back, I was quite fortunate to work in an environment where the system administrators wouldn’t let me walk over and tell them, there’s an outage right now, and walk away. They always requested more details. If you didn’t perform any troubleshooting, they would ask direct questions like- What’s changed? Can you ping the gateway? And the list goes on.

Working in an environment like this instilled troubleshooting into my mindset. Throughout my career, I’ve found that not everybody has this mentality. I can’t tell you how many times I’ve been called in the middle of the night during a maintenance window from my NOC stating that mail is down or this application is down after the server has been rebooted. I then ask- Are the services running? Again, this is not meant to be a rant. It’s just an example to highlight the fact that not everyone performs basic troubleshooting on a given issue.

Recent Example

Normally, when working with third-party vendors, I begin a migration project by discussing the details, and it follows the pattern below:

• Spin up a new server/VM/EC2 instance.

• Provide VPN access to the third-party vendor.

• Work with the vendor to install the software.

• A third-party vendor performs some tweaks to the application and tests it.

• I work with the vendor and client to schedule a cutover.

• The vendor performs data migration after hours.

• My desktop team and I assist with onsite support to ease the transition.

After that, it’s just a matter of testing and ensuring that the clients are all working.

I recently had a project where I had to upgrade a Sage software product. I called their support and laid the groundwork for the tasks listed above. They told me I had to do it all, but they could send me a link from their KB about how to do it. Their support for the product was different, and they did not perform any migration services, etc.

I went through their KB articles and found the process straightforward. I installed the software on a new server and scheduled the cutover. This is where things got interesting. I initially ran into issues exporting the main system backup. I received an error: “Error 333: Cannot open file.csv.”

This is why I am writing this. I’m not an expert in Sage software, and I don’t know what this error code is, but… let’s troubleshoot it! Where is this file in question? Is it a permission issue? I went ahead and found the file in question, checked permissions, and found that everything looked good. I also thought maybe Office had to be installed on the system. I installed Microsoft Office and tried it again. Same error. From there, I went through the server again, looking for anything that stood out. After digging around a little more, I found the previous IT vendor was running Google Drive sync to their account as a form of backup on the entire directory (SMDH). I killed the Google sync, and the backup worked!

Final Thoughts

Lesson learned? Whether working with in-house systems or third-party vendors, resisting the urge to throw up your hands at the first sign of an error code can save time and frustration for everyone involved. A troubleshooting mindset can transform potentially chaotic situations into minor bumps along the road to a successful project completion.