Milestone MIP SDK vs Genetec SDK: Choosing Which VMS to Build On

We get asked this at the start of most product engagements: a company has a capability — analytics, access control, LPR, sensor fusion, alerting — and knows it has to live inside a video management system, but hasn't committed to which one. Milestone XProtect and Genetec Security Center are the two that come up, and the honest answer is that they're built on different assumptions about who gets to extend them.

What follows compares them on the dimensions that actually change a project plan. It is not a feature-count exercise; both platforms can do the things in this article.

The short version

The rest of this article is why each of those rows reads the way it does.

1. Cost of entry: closer than its reputation suggests

Genetec has a reputation for being the closed one, and it is worth correcting because it leads teams to the wrong platform.

Milestone publishes the MIP SDK openly and its Technology Partner Program is free to join. A developer can download the SDK, build a sample, and watch a plugin load in Smart Client inside a day.

Genetec's route is an application rather than a download, but it is not a paywall. The Development Acceleration Program (DAP) is open to technology partners, integrators and end users alike, and joining gives access to the SDK documentation, the installer and a Security Center development licence. What is paid is the tier above that: an SDK assistance plan, which buys specialised help from Genetec's SDK technical team, and which in some plans includes integration certification. So a team can evaluate Genetec, build against the SDK and run it on a development licence before spending anything — they just can't call Genetec's SDK engineers while doing it.

The real asymmetry is therefore narrower than the folklore: it is a form and a few days versus a download, plus a decision later about whether you want vendor engineering support and certification bundled. That is a scheduling difference, not a strategic one. Tiers and inclusions change — confirm the current ones with Genetec rather than with any third-party summary, this one included.

Two things that do follow from it. Milestone is still marginally faster to a first experiment, which matters when you are testing a hypothesis rather than building a product. And Genetec's application step, modest as it is, keeps the plugin ecosystem around you smaller and less crowded — which, if you are selling a product rather than shipping one integration, is worth more than a day saved at the start.

2. Where your code is allowed to live

This is the real architectural difference. The two platforms give you a different shape of extension point.

Milestone gives you breadth. Four independent surfaces, each with its own plugin type, all discovered through the same PluginDefinition entry point. You can ship a plugin that only adds a Smart Client side panel and nothing else, and it's a complete, sensible product. Our Smart Client and Event Server guides cover two of those surfaces in code.

Genetec gives you depth. Its SDK is split by concern — a Plugin SDK for server-side custom roles with database support, a Workspace SDK for client-side extensions inside Security Desk and Config Tool, and Platform and Media SDKs for core functionality and video — but the centre of gravity is the Plugin role running on the Genetec Server, supervising agents, configured from Config Tool exactly like Genetec's own Archiver or Access Manager roles. The payoff is custom entity types: register one and your objects join Security Center's existing permission model, audit trail and entity browser, and become referenceable from macros, schedules and reports. You do not rebuild any of that.

That single capability is the strongest technical argument for Genetec. If your integration introduces new things that operators need to find, permission, schedule and report on — sensor sites, zones, assets, external subsystems — Genetec gives you a first-class home for them. On Milestone you would model the same concepts inside your own plugin and carry the plumbing yourself.

3. Events: the model you'll be fighting or leaning on

Both platforms let you introduce your own events and alarms, and in both cases that's how an integration becomes operationally useful rather than merely visible.

On Milestone you register custom event and alarm kinds with EnvironmentManager and fire them; XProtect's Rules and Events engine then treats them like any built-in event, so integrators can wire your detections to recording, PTZ presets, outputs or notifications without you writing that logic:

// In a Background plugin's Init()
EnvironmentManager.Instance.RegisterKind(FieldAlarmKind.Definition);

// Later, when the external system reports something
EnvironmentManager.Instance.FireEvent(
    FieldAlarmKind.Build(camera, "PerimeterBreach", severity: 2));

On Genetec the analogous move is raising events and custom alarms from the plugin role, where they flow into Security Center's alarm handling, macros and reporting. The mechanics differ; the design question is identical and it's the one that actually matters: what granularity of event do you emit? Too coarse and integrators can't build useful rules. Too fine and you produce an event storm that the alarm engine — and the operator — drowns in.

One concrete difference worth planning for: severity scales don't line up. Genetec alarm priorities run 1–255, which in practice gets banded into ranges. XProtect ships three priorities — Critical, High and Medium — with Low typically added as a custom priority. Any product spanning both needs an explicit, documented mapping between its own severity model and each platform's, and that mapping is a product decision, not an implementation detail to be improvised per customer.

4. Deployment: the friction your integrator absorbs

This is the dimension most often left out of SDK comparisons, and the one your support inbox will care about.

Milestone. Client-side plugins are deployed by placing assemblies in the MIPPlugins folder on each machine that needs them; Event Server plugins go on the Event Server and the service restarts to load them. Simple per machine, but note "per machine" — a plugin that adds a Smart Client panel has to reach every workstation, and on a site with fifty Smart Clients that's a software distribution problem you should solve with an installer and existing deployment tooling rather than by documenting a manual copy.

Genetec. Heavier but more centralised on the server side. The plugin installs on the Genetec Server, then an administrator adds it as a Role in Config Tool, assigns it to a server and points it at a database. Client extensions still have to reach each Security Desk and Config Tool workstation. In exchange, the role participates in Genetec Server's supervision — including role failover, where a properly written plugin recovers its agents cleanly when the role relocates to a standby server. Milestone has no equivalent to hand you; resilience of a background plugin is your design problem.

If your product will be deployed by third-party integrators rather than by you, weight this row heavily. Deployment friction is what generates support tickets, and support tickets are what determine whether integrators recommend you again.

5. Certification, licensing and the customer's paperwork

Neither platform lets you ship a commercial product into the ecosystem without going through the vendor.

Milestone runs a solution certification programme testing functionality, usability and performance, with certification as the gate for formal partner admission, followed by Marketplace verification and a Solution Finder listing — the full path is in our certification guide. Genetec's equivalent runs through its partner and development programmes, and for a commercially distributed plugin, governs both certification and how the plugin's licensing is issued.

The part that reaches your customer is where the two genuinely differ. On Genetec, the end user's Security Center licence has to include a certificate for your plugin before it can be installed: once your integration is ready for production you get a part number and production certificate from Genetec, and the customer updates their licence to carry it. That is a procurement step someone has to complete before your software runs at all. On Milestone, plugins may use the MIP plug-in licensing framework, where the plug-in licence is added to the customer's Software Licence Code as a sub-product — identified by your company name, a plug-in ID and a licence ID — and activated online or offline from the Management Client like any other licence. Or the plugin can stay outside that framework and carry its own entitlement.

Both mechanics are vendor-specific and both change; confirm them with the vendor before telling a customer that nothing on their licence changes. We go into the whole picture in licensing and distributing a commercial VMS plugin.

6. So which one?

The decision is almost never about the SDKs. In order of how much weight we'd actually give each:

1. Where your customers already are. This dominates everything below it. Nobody replaces their VMS to adopt an add-on. If your pipeline is Genetec accounts, build Genetec, whatever the SDK ergonomics.
2. Whether you're introducing new objects or new behaviour. New objects operators must find, permission and report on → Genetec's entity model earns its cost. New behaviour on existing objects, or a new operator view → Milestone's breadth gets you there faster.
3. How fast you need a first experiment. Milestone's open download is quicker off the mark than DAP's application, so it remains the marginally cheaper place to prove a hypothesis — but this is days, not quarters, and it should never override the first point on this list.
4. Who deploys it. Self-deployed → either. Deployed by integrators at scale → think hard about the per-workstation client rollout on both platforms, and budget for a real installer.
5. Whether server-side resilience is a product requirement. If your plugin must keep running through a server failure, Genetec's role failover is a genuine advantage you'd otherwise build yourself.

Building for both without building everything twice

Most products that succeed on one platform get asked for the other within a couple of years, so it's worth structuring for that from the start — without over-abstracting.

What travels: your domain logic, storage, analytics, rules, scheduling, reporting, and any web UI. That should be a platform-neutral service that knows nothing about either VMS.

What doesn't travel: the adapter. Event and entity models, UI extension points, configuration surfaces and deployment mechanics are genuinely different, and an abstraction layer that pretends otherwise ends up expressing only the intersection of both platforms — which is a worse product on each. Keep the adapters thin, separate, and honest about what only one platform can do.

The practical test for a good split: adding a third platform — Bosch BVMS, Avigilon, Axis Camera Station — should mean writing one new adapter and touching nothing in the core. If it means editing the core, the boundary is in the wrong place.

Where projects usually need a specialist

The expensive mistakes here are made in week one, not in the code. Choosing the platform your engineers find pleasant rather than the one your customers run. Committing to an abstraction layer before you've built even one adapter and learned what the differences actually are. Discovering during a customer's procurement cycle that loading your plugin requires a licence change nobody budgeted for. Designing an event model at the wrong granularity and having every integrator build workarounds.

We build on both platforms — Milestone XProtect plugin development and Genetec Security Center plugin development — which mostly means we've made these calls often enough to know which ones are reversible and which aren't.

Working with Xplug.in

Tell us what the capability is — we'll tell you which platform it belongs on

• A platform recommendation before a proposal. Send the capability, who your customers are, and how it gets deployed. You get back which platform we'd build it on and why, which SDK surface it needs, and what each option costs you in certification and customer-side licensing.
• An architecture that survives the second platform. Where the core/adapter boundary goes, what your event and severity model should be on each side, and which parts of the design are reversible later and which aren't.
• The plugin built and certified on Milestone, Genetec, or both — tested against real installations, and taken through the vendor's certification process rather than left working-but-unverified.
• Source and IP transferred to you at delivery, plus version tracking as XProtect and Security Center releases move underneath it.

Get a platform recommendation Schedule a technical demo

Xplug.in is a Milestone Technology Partner and Genetec Technology Partner, working within the Development Acceleration Program, with 140+ plugins shipped since 2014 across both platforms. Write to contact@xplug.in or use the form — we'll answer the platform question even if you build it yourself.

Questions we get asked

Which is easier to start building on, Milestone or Genetec?

Milestone, but by less than its reputation suggests. The MIP SDK is openly available and the Technology Partner Program is free to join, so a developer can download the SDK, run the samples and have a plugin loading in Smart Client the same week. Genetec's route is an application rather than a download: joining the Development Acceleration Program gives you the SDK documentation, the installer and a Security Center development licence, so you can build and test before spending anything. What is paid is the SDK assistance plan above that, which buys help from Genetec's SDK technical team and in some plans includes certification. The practical gap is days, not quarters, and it should never outweigh which platform your customers actually run.

Can one codebase support both Milestone XProtect and Genetec Security Center?

Partly, and it is usually the right architecture. Your domain logic, storage, analytics, rules engine and any web UI should be platform-neutral and live in a core service. What cannot be shared is the platform adapter: the event models, entity models, UI extension points and deployment mechanics are genuinely different, so plan on a thin per-platform layer rather than an abstraction that pretends the two are the same.

Do end customers need an extra licence to run a third-party plugin?

On Genetec, plan for it. The customer's Security Center licence has to include a certificate for your plugin before the plugin can be installed: you obtain a part number and production certificate from Genetec once the integration is ready, and the customer updates their licence to carry it. That is a procurement step on their side. On Milestone, plugins may use the MIP plug-in licensing framework, which adds the plug-in licence to the customer's Software Licence Code as a sub-product and activates online or offline from the Management Client, or stay outside it and carry their own entitlement. Either way, confirm the current mechanics with the vendor before you promise a customer that nothing changes on their licence.

Which platform gives a deeper in-product integration?

Genetec's entity model goes deeper. A Genetec plugin can register custom entity types that inherit Security Center's permission model, audit trail and entity browser, so your objects behave like native ones in macros, schedules and reports. Milestone's plugin surface is broader instead of deeper — Smart Client, Management Client, Event Server and Recording Server drivers are all extensible, giving you more places to appear with less plumbing inherited for free.