Navigating a Failed Support Relationship

Who among us doesn’t want to experience healthy, enduring relationships, that provide for our needs?  In an ideal world, we’d all reap the benefits that such continuity provides.  Evidence shows that many potential clients have found this difficult to achieve.  Relationships fail.  Support relationships fail with consequences.  Should the need arise, you will want the ability to transition to a new support provider, with minimal disruption, and pain.  The inability to do so, is often attributable to documentation deficiencies, and device lockouts.  Both are preventable.

Accurate and comprehensive documentation is a critical element in maintaining control of your network.  Used appropriately, it will minimize configuration errors that can result in increased down time, and compromised network security.  An organized reference of your network's configuration is a common starting point for diagnosis, and a valuable tool in reducing time-to-resolution.  It will protect you from the ill affects of support transitions, by enabling new personnel to be dialed-in more quickly, and without the repetitive expense of discovery.

During the course of your existing support relationship, you should accumulate service records of past events for future reference.  You should ensure that appropriate investments are made in documenting the configuration of your network.  A copy of the documentation set should remain on-site and client accessible, with suitable access restrictions.  Your documentation should be in such a state that support transitions can occur expeditiously, and with confidence, should the need arise.  If you have not invested in documentation, or your existing support provider maintains exclusive access to documentation, a support transition will be needlessly painful, and potentially expensive.

Quality documentation is an asset.  Invest appropriately.

Although it’s reasonable for the administrator(s) of your device(s) to maintain exclusive administrative control, free of interference and configuration tampering, it’s important not to dismiss the privileges and responsibilities of ownership.  You should never be locked out of a device you own.  Login credentials should be documented and on-site, with suitable access restrictions.  Too frequently, we receive calls from potential clients reporting that an existing support relationship is failing; that they want to transition, but they are not in possession of login credentials or device configurations (documentation).  How attractive do you think that proposition is?

Consider the implications with Cisco IOS devices.  Without credentials it will be necessary to perform a password recovery procedure, which requires a device reboot.  If the administrator has not written configuration changes from the running-config to the startup-config, these differences will not survive the reboot, and the device will not function as it did prior to the reboot.  This could lead to a service outage.  The situation is worsened by the absence of documentation, and time constraints that don’t allow for adequate discovery.

Depending on your environment and chosen hardware platform, a reasonably modest configuration file may contain 1500 lines of commands.  The robust feature set of a Cisco IOS device can result in implementations that uniquely reflect the abilities and philosophy of an administrator.  Allow your new support provider an opportunity to review configuration files, and develop an understanding of the nuances of their predecessor's configuration.  During the course of a configuration review, they may contend with configuration errors, inefficiencies, or residual commands that should be retired.  Review may be hindered by the absence of comments, or sub-optimal naming conventions that are confusing, or even misleading.

The remainder of the documentation set will require review as well. In some cases, the accuracy of the documentation will need verification.  Your new provider needs to establish familiarity with your network prior to implementing changes, in order to minimize the risk of errors and wasted effort.

If your existing relationship is salvageable, meet with your support provider to discuss existing documentation deficiencies, and / or access to login credentials.  Set clear expectations, and be prepared to make appropriate investments.  Yes, documentation takes time.  Review the documentation your provider produces, and ensure that it is of sufficient quality.  Address any deficiencies.

If you’ve invested appropriately, and taken steps to prevent device lockout, then transitioning to a new provider shouldn't result in a major setback, or require immense effort to get new support personnel up to speed.  If you’ve not done so, you’re a hostage.  Learn from your mistakes.

Don’t allow an existing support relationship to reach an advanced state of decay before transitioning to a new provider.  Make an effort to remedy documentation deficiencies, and gain access to login credentials prior to transitioning.  Allow for some overlap, if possible.  Give your new provider something to work with, and improve your odds for a successful relationship.  If you don’t make the effort, the transition will likely be painful, and self-inflicted.  Recognize what is in your best interest, and act accordingly.  Please.