How to Replace VMS Software

The uproar over Milestone's unprecedented new support charges has motivated many to replace existing VMS software with new ones. However, how can this be done? While it may be less expensive to replace VMS software than DVR appliances, many factors still come into play. This guide reviews the key considerations providing a checklist of issues to verify and work through.

Migrating from one VMS software to another faces two categories of issues: (1) potential dealbreakers and (2) logistical challenges. Here are the potential dealbreakers that could make migration untenable:

• Cost of Migration
• Compatibility with Existing Systems
• Accepting New User Interface

In addition, a number of logistical issues might not block the move but can make it more or less painful:

• Testing New Setup
• Hardware Required
• Using Old or New Hardware
• Accessing Old Video
• Installing New Clients
• Re-training Operators

We review each one, starting with the dealbreakers:

Cost of Migration

Migration can be expensive as new VMS licenses need to be purchased. These are somewhat 'duplicative' as VMS licenses for the current system are already owned. If you are currently paying a yearly maintenance/support fee, eliminating that might offset a small amount of this cost (perhaps 10%). More importantly, you should check if the new VMS vendor offers any promotions or discounts for replacing a competitor's VMS. This often happens and can substantially reduce the cost. Also, if your current VMS vendor charges for ongoing maintenance and your new one does not, this is another good way to justify the migration.

Additionally, an integrator will need to test, deploy and verify any problems with the integration. Even on a small to mid size VMS system of 8 - 32, this could take a day or two. This might add a thousand dollars or more in cost.

The good thing with VMS replacement is that hardware can typically be reused, saving money. However, the software and services cost are still significant.

[Option: Consider if the integrator can re-sell the outgoing VMS licenses to someone else. See this discussion.]

Compatibility with Existing Systems

Migrating VMS systems may break integrations with various existing systems. Be careful about this. For instance:

• Verify that the new VMS supports all of your existing camera models. If they do not, you will essentially lose those cameras.
• Make sure to check for key feature support - like PTZ controls or panoramic / immersive video controls. You might still get video but lose important features key to your cameras.
• Ensure that any 3rd party security systems can be integrated. For example, if you integrate with access control, PoS systems or even keyboard controllers. The new VMS system may not support or might charge significant extra licensing fees.

Accepting New User Interfaces

Over time, users get accustomed to a specific user interface, regardless if it is 'good' or 'bad'. Even if the new VMS system offers similar functionalities, they may do it in different ways or with varying controls. Make sure the primary operators review and try out the proposed new VMS user interface. They may hate it (or love it) and it is best to know up front so that opposition does not occur after migration. This is hard to predict abstractly as it often depends on personal idiosyncrasies.

Those are the big 3 issues to review before approving a project. However, before executing it, a number of important logistical steps need to be done.

Testing the New Setup

Before you move to a new VMS, load that VMS on a temporary machine and connect it to existing cameras and systems. Make sure that things actually integrate and that no surprises occur (e.g., the VMS not being supported by the existing OS, problems connecting to cameras, etc.). Equally importantly, test to see if the hardware / VMS can handle the existing load.

Hardware Required

VMSes can vary on how much computing resources they need even when connected to the same cameras. It is hard to predict this in advance but the new VMS system may need more (or less) RAM, CPU, etc. than the existing one.

Using Old or New Hardware

A major logistical decision is whether to use the existing PC/server that the old VMS is running on or to use a new one. If you use the existing one, you could face some conflicts if they are both installed during the cutover period. To that end, it is likely safer to use a new clean PC/server and then to repurpose the machine running the old VMS when it is brought offline.

Accessing Old Video

It is almost inevitable that you will keep the old VMS system online for a period of time in case you need to access older video from the decommissioned VMS. It is typically not possible to retrieve video stored on the old VMS from the new one's client. However, you may still need to retrieve older video if you have an incident reported. The rule of thumb is to keep the old system online for the number of days you typically store video. For instance, if video is recorded for 30 days, then keep the old VMS up for a month.

Installation of new clients

Remote clients for the new VMS will need to be installed on operator workstations. This is a challenge of accessibility and scheduling, especially when users are not local. Taking advantage of remote support utilities can be helpful for installing new thin clients. This effort should be coordinated with IT, who can help provision the work and may also be interested in taking advantage of the opportunity for other updates or maintenance.

Training operators

Migrating operators to a new VMS system can be a surprisingly difficult aspect of an system change, especially if existing operators have used the previous platform for a long time. Becoming oriented with new software can be very frustrating for someone with experience on a different system. Review the most common use cases for the operators and document how to do this with the new VMS. This can be printed out and left next to the operator workstations as well as emailed out to the team using the new VMS.