Matrix42 ESM Platform Migration Guide
Audience: Technical Experts (Customers & Partners)
Context: Cloud Your Way Initiative
Overview
As part of the Matrix42 strategic initiative “Cloud Your Way,” the Enterprise Service Management (ESM) platform is undergoing a fundamental modernization to support deployment within Linux containers.
This document outlines:
- The target architecture and transformation goals
- Key delivery milestones
- Planned breaking changes
- Guidance for adapting existing extensions to ensure compatibility with the modernized platform
Target Architecture
Goals
- Modern Technology Adoption: Introduce current and widely adopted technologies to enhance development speed, talent acquisition, security, and compliance.
- Optimized Deployment: Transition to a containerized, Linux-based architecture for efficient operations, cost reduction, and zero-downtime maintenance.
- Improved Reliability: Isolate background processes to increase system stability and maintainability.
- Scalability & Security: Enable future scalability and enhance security through sandboxed execution environments.
- Flexible Cloud Support: Ensure deployment compatibility across public and private clouds using immutable containerized applications
Architecture 2026
Key Changes:
- Introduction of the Functional Worker process, replacing legacy components: HostCommon, HostScheduler, and Worker.
- Applications run on .NET Core:
- Compiled for Windows (on-premises)
- Compiled for Linux (containerized deployments)
- All backend custom logic now runs in sandboxes (on Functional Worker).
- The Application Server becomes immutable—unchanged during extension installations.
- All legacy components incompatible with .NET Standard are removed or replaced.
Deployments
Classical On-Premise (Windows)
-
Windows-based installations remain supported.
-
All Matrix42 services compiled with .NET Core for Windows.
-
Functional Worker runs as a Windows Service.
Private Cloud
- Each release includes Linux Docker Images for Kubernetes-based deployment (BYOK model).
- Delivered images:
- ESM Services
- ESM Setup
- ESM Functional Worker
- Includes deployment scripts and automation recipes.
Public Cloud
Operated in Azure Kubernetes Services (AKS) using Linux containers.
Implementation Plan
Transition Strategy
- Use .NET Standard as an interim compatibility bridge for existing extensions.
- Target eventual migration to .NET 9+ once ecosystem readiness is ensured.
Legacy Component Removal
The original product uses a bunch of components and technologies which are not compatible with .NET Core, therefore they planned to be removed or replaced
|
Component |
Change Version |
Replacement |
|---|---|---|
|
Microsoft WCF |
12.1.2 |
Replaced with Web API |
|
Access Database Engine |
12.1.2 |
|
|
AutoMapper.dll |
12.1.3 |
Updated to version 10.1.1.0 |
|
.NET Remoting |
12.1.5 |
Web API, Queue |
|
.NET Framework |
12.1.6 |
.NET Core |
Migration Roadmap by Release
Release 12.1.3
Changes
- Core assemblies (Contracts, Data Layer, Behaviors, Engines) migrated to .NET Standard 2.0.
- New SQL API introduced for non-DataLayer operations.
- Replace System.Data.SqlClient with Microsoft.Data.SqlClient for cross-platform compatibility.
- Enhanced hosting support for resolving multiplatform dependencies.
- New Middleware Behaviors model introduced. See more details on Middleware Behaviours
Required Actions
- Use the new SQL API for database transactions.
- Rebuild and republish extensions if breaking changes are detected.
- Set MinimalRequiredVersion=12.1.3 in updated packages.
- Optionally target .NET Standard.
- Begin adopting the new Behaviors model.
- Replace Business Engines call to Web Services
Business Engines
In earlier versions, the first generation of Service Layer–hosted services were run within the HostCommon process and declared in the Application as Engines. These services could be invoked from any other application process using code like:
using update4u.SPS.Engines; EngineProxy.GetWorker(typeof(IInventoryDemandsWorker)).RemoveInvalidInventoryDemands();
This approach has been deprecated and removed as of version 12.1.4.
If your Extension relies on this pattern, you should now either use the corresponding Web API, or access the relevant business components directly.
Release 12.1.4
Changes
- Legacy HostCommon and HostScheduler removed.
- Background Engines moved to Functional Worker
- Nearly all core assemblies now use .NET Standard.
- Background tasks (excluding Workflow Engine) executed in .NET Core Functional Worker (Linux).
- Extensions run in sandboxed environments.
- Introduction of an agnostic API controller for Web API in sandboxed packages.
- Introduction of an agnostic API for Engines.
- PowerShell 7 Execution Engine
Required Actions
- Migrate custom Middleware Behaviors to the new model.
- Ensure full sandbox compatibility for all extensions.
- Compile and publish extensions targeting .NET Standard.
- Begin adopting the agnostic API controller for custom logic.
- Begin migrating Powershell scripts from version 2 to version 7
Release 12.1.5
Changes
- Web Server now runs on .NET Core.
- Custom code executes only within Functional Worker sandboxes.
- Agnostic Workflow Activities API introduced.
Required Actions
- Implement workflow activities using the new agnostic API.
Release 12.1.6
Changes
- Workflow Engine fully migrated to .NET Core Functional Worker.
- Only PowerShell 7 supported executed on .NET Core Functional Worker.
- .NET Framework Functional Worker is discontinued
- All assemblies compiled and delivered on .NET Core