How long System Center Orchestrator is supported
Planning starts with the Orchestrator version you run. Microsoft sets a fixed end of support for each version (Fixed Lifecycle Policy). The table lists the last supported day:
| Version | Mainstream support | Extended support |
|---|---|---|
| System Center 2016 Orchestrator | 2022-01-11 | 2027-01-11 |
| System Center 2019 Orchestrator | 2024-04-09 | 2029-04-09 |
| System Center 2022 Orchestrator | 2027-04-13 | 2032-04-13 |
| System Center 2025 Orchestrator | 2030-01-08 | 2035-01-09 |
Extended support for System Center 2016 Orchestrator ends on January 11, 2027; after that, Microsoft ships no more security updates. Newer versions stay supported much longer, so changing tools is not mandatory. It is a choice between several paths.
The paths after SCOrch 2016
- Upgrade to System Center 2025 Orchestrator: runbooks stay in the same environment, with support until January 2035. System Center licensing and operations remain as they are.
- Azure Automation: Microsoft offers a migration toolkit that its own guide labels as beta. It converts runbooks into graphical runbooks. Monitor activities, variables and connections are not carried over, and reaching on-premises systems requires a Hybrid Runbook Worker.
- Service Management Automation (SMA): SMA runs runbooks in your own datacenter but does not support graphical runbooks. According to Microsoft, Orchestrator runbooks have to be rewritten in PowerShell by hand.
- NodePilot: an open-source, self-hosted workflow orchestrator for Windows with a graphical designer and an importer for
.ois_exportfiles. Runbook automation stays inside your network; the effort goes into reviewing and completing the imported workflows.
The right path depends on licensing, cloud strategy and the Integration Packs in use. Either way, an inventory of your existing runbooks comes first.
Start with your existing runbooks
Replacing System Center Orchestrator involves more than copying visible activities. Connections, conditions, Published Data and execution identities also determine a runbook's behaviour. NodePilot imports SCOrch exports in .ois_export format to use existing automation as a starting point.
What the import does and what needs review
Supported activities are mapped to NodePilot activities. Unsupported activities remain visible as disabled placeholders. An import report records areas that need attention. Encrypted credentials are not reconstructed, and imported workflows start out disabled.
The article Importing SCOrch runbooks and reviewing the result explains the process and its limits. NodePilot does not promise to replace every System Center Orchestrator integration or behaviour.
Evaluate a migration in small steps
- Select a representative runbook and define its expected results.
- Import the export and review every warning in the import report.
- Check target machines, service accounts, data references and schedules.
- Compare successful and failing cases with the previous behaviour in a test environment.
- Explicitly enable the reviewed workflow only after those checks.
SCOrch and NodePilot compared
| Aspect | System Center Orchestrator | NodePilot |
|---|---|---|
| Target systems | agentless | agentless over WinRM, the same model |
| Authoring | Runbook Designer desktop application | browser designer with live status for every step |
| Testing | Runbook Tester with breakpoints | step debugger in the real engine, with conditional breakpoints and runtime variable overrides |
| Versioning | not built in | every edit kept as a version, with diff and rollback |
| Interfaces | web API to start and monitor jobs | REST API for every operation, np CLI and MCP server |
| Database | SQL Server | PostgreSQL or SQL Server |
| Licence | commercial | Apache 2.0, no per-host cost |
| Support | vendor | community; a single-maintainer open-source project |
The table compares capabilities. Whether a specific runbook works without rework only shows after importing and testing it.
Your own infrastructure and an open licence
NodePilot runs in your Windows environment and is released under Apache 2.0. Review the self-hosting requirements and installation guide during evaluation. An open-source licence does not include a support contract or an operational guarantee.
Example: Migrate a daily status check
Start with a runbook that reads a service state on a test machine and passes the result on. Record its expected output and failure behaviour. Import the export, replace placeholders where needed and test both an existing and a deliberately invalid service name. Compare output, branching and logs before enabling the schedule.
| Review area | SCOrch starting point | Check in NodePilot |
|---|---|---|
| Activities | Runbook and Integration Packs | Mappings in the import report; replace placeholders |
| Data flow | Published Data and link conditions | Variable references and branches with real test values |
| Identity | Execution account and stored credentials | Reconfigure credentials and verify target access |
| Schedule | Existing triggers | Review triggers; imported workflows start disabled |
SCOrch import, activity mapping and limitations · Explore execution and troubleshooting in the browser demo.