Milestone plugin development,
built on the MIP SDK.

What a Milestone plugin actually is

The Milestone Integration Platform (MIP) SDK is Milestone's official framework for extending XProtect. A plugin is a C# / .NET assembly that XProtect loads at runtime and then treats as part of the product: it draws inside the operator's console, subscribes to the same event bus, and reads and writes configuration through the same infrastructure as anything Milestone ships itself.

That distinction matters commercially. A plugin is not a second application sitting beside the VMS with its own login and its own window. The capability appears inside the software the operator already has open at 3am, which is the only place it will reliably get used.

The four places a plugin attaches

Smart Client — the operator surface

Where most projects start. A ViewItemPlugin puts your own pane into the view layout alongside live video; a SidePanelPlugin docks a panel beside it. Toolbar and workspace plugins extend what an operator can do with the camera already in front of them — overlays, custom search, controls for a third-party system. Our Smart Client plugin guide walks through the implementation.

Event Server — the headless side

Runs without a user. This is where custom events, alarm handling and rule logic live, and where a third-party system's state becomes a native XProtect alarm that behaves like every other alarm in the system. See the Event Server plugin guide.

Management Client — the administration surface

Your plugin needs configuring, and administrators should not have to leave the tool they configure everything else in. A Management Client extension puts your settings where they expect to find them.

Recording Server device drivers

For hardware XProtect does not speak to natively. A driver brings a proprietary or non-ONVIF device into the VMS as a first-class device rather than a special case — recorded, searchable and exportable like any camera.

What we are asked for most

• LPR and ANPR — plate capture with watchlist alerting. We shipped one across 400+ cameras for a national transit authority.
• Alarm routing and escalation — getting the right alarm to the right responder, and escalating when nobody acknowledges.
• Access control event fusion — door and badge events unified with video on a single operator timeline.
• AI analytics — intrusion, object and behaviour detection, running at the edge or server-side via ONNX and CUDA.
• Device and protocol bridges — ONVIF, RTSP, MQTT and REST endpoints brought into XProtect.
• SIEM and audit export — events and audit trails pushed out over syslog or REST, with an on-premises failover queue.

Versions, compatibility and the long tail

We target XProtect Corporate and Expert from 2024 R1 forward, and we build for thousand-camera deployments with HA failover rather than for the demo bench. The harder part of Milestone work is not the first release — it is the fifth year. Milestone ships regularly, and a plugin that nobody tracks quietly stops loading after an upgrade. Version-tracking every release is part of how we support what we build.

Certification and the Marketplace

We hold the developer credentials to ship production software inside the Milestone ecosystem and guide you through Milestone verification and, where you want it, listing on the XProtect Marketplace. The certification guide covers what the process actually demands.

How an engagement runs

Discovery first — a short technical call where we work out whether what you want is even the right shape for a plugin. Then architecture, then working builds from week one, demonstrated weekly on real hardware rather than a slide. Certification and handover close it out.

Most projects ship a first production build in eight to twelve weeks. Certification-heavy work and large platform bridges run longer, but you get a fixed milestone plan after the architecture phase rather than an open-ended estimate. Every engagement has a named lead engineer who stays with it, and the IP transfers to you at delivery — we retain only the internal tooling and shared libraries that predate your project.

Afterwards you can take the plugin in-house or leave it with us on a support plan that tracks every VMS release and keeps compatibility current under an SLA. Most clients choose the second.

Also building on Genetec? See Genetec plugin development — where a customer runs both platforms we keep one shared core with a thin platform layer on each side.