Skip to content
Artrilogic
.NET modernisation at enterprise scale

Microsoft helps modernise your .NET application. Artrilogic helps modernise the estate around it.

Microsoft’s modernisation tooling is making application-level upgrades faster than they have ever been. That is a genuine shift, and we use it.

Enterprise modernisation, though, is rarely one repository, one application or one framework upgrade. Artrilogic coordinates the systems, dependencies, environments, validation and institutional knowledge required to modernise entire .NET estates safely and repeatedly.

Talk to us about your .NET estateSee how the approach works

Microsoft modernises applications. Artrilogic industrialises modernisation.

  • We are not building another upgrade agent. Microsoft’s tooling can be one of the executors inside our process.
  • Our boundary starts where a repository-level upgrade stops being enough to finish the job.
  • The difference is not that our AI writes better C#. It is knowing what must change, in what order, and what evidence proves it is safe.
Where the market is going

The .NET modernisation model is changing.

Microsoft now ships AI-assisted modernisation across assessment, planning, transformation, build and test validation, and iterative upgrades. The GitHub Copilot upgrade agent runs a documented assess, plan and execute workflow with more than thirty built-in upgrade skills, and the Modernize CLI takes the same model across multiple repositories in batch.

We see that investment as validation of where the industry is heading, not as competition. Modernisation is becoming an evidence-producing loop rather than a one-off project, and we agree with that shape. Our focus is the layer above the individual upgrade: coordinating modernisation across systems, repositories, environments and business workflows.

  1. Assess
  2. Plan
  3. Transform
  4. Validate
  5. Iterate
The key difference

Application modernisation and estate modernisation are different problems.

Both are real work. They just have different failure modes, and only one of them is solved by transforming the code in front of you.

The application view

Microsoft provides sophisticated tooling for modernising .NET applications: framework upgrades, dependency replacement, and code transformations that would otherwise take an engineer weeks. Inside a repository, this is very good.

RepositoryOne solution, one team
Source
Dependencies
Framework
Tests
Upgrade agentTransformation applied and the build validated
Modernised project
A repository-level upgrade: source, dependencies, framework and tests go through an upgrade agent and come back as a modernised project.

The estate view

Artrilogic starts a step earlier, by understanding the relationships between applications before transformation begins. Which systems share a library. Which share a database. Which one quietly breaks when another is redeployed.

Application estateMany systems, many owners, one business
Web applications
APIs and services
Background jobs
Shared libraries and internal packages
SQL Server
Integrations and queues
Infrastructure
Artrilogic modernisation control planeKnows what depends on what, and in which order it can safely move
An application estate: web applications, APIs and background jobs sit on shared libraries, shared data, integrations and infrastructure. Artrilogic maps those relationships before any transformation starts.
Side by side

Where the two overlap, and where they do not.

Microsoft's column below is drawn from official Microsoft and GitHub documentation, checked in August 2026. Where Microsoft has a capability, we say so.

Assessment and planning

  • .NET application assessment

    Microsoft: Strong

    Analyses project structure, dependencies and code patterns, then writes an assessment file into the repository for review.

    Artrilogic: Strong

    The same analysis at repository level, plus discovery across the estate: which systems call which, what shares a database, what nobody owns.

  • Upgrade planning

    Microsoft: Strong

    Produces an ordered plan and task list, and recommends a bottom-up, top-down or all-at-once strategy for the solution.

    Artrilogic: Strong

    Planning extends past the solution boundary to sequencing between applications that share libraries, contracts, schedules and data.

  • Cross-application dependency mapping

    Microsoft: Supported for repositories

    Multi-repo assessment produces aggregated reports with cross-repository analysis and dependency mapping.

    Artrilogic: Core capability

    The graph includes what is not a repository: databases, queues, integrations, scheduled jobs, infrastructure and deployment paths.

Transformation

  • AI-assisted code transformation

    Microsoft: Strong

    Fifteen managed scenarios and more than thirty built-in upgrade skills, loaded automatically as the agent meets the relevant code.

    Artrilogic: Routed to the best executor

    We do not compete here. Microsoft's tooling is a first-class executor inside our process, alongside other models and deterministic transforms.

  • .NET Framework to modern .NET

    Microsoft: Yes

    Any .NET Framework version to .NET 8 or later, plus .NET Core 1.x through 3.x and .NET 5 or later onto current .NET.

    Artrilogic: Yes

    The same target, chosen per project rather than per solution, and sequenced so shared libraries move before the systems that depend on them.

  • Web Forms modernisation

    Microsoft: Yes

    A managed scenario upgrades ASP.NET Web Forms applications to Blazor Server, including project setup and static asset migration.

    Artrilogic: Yes, with screen-level proof

    The transformation matters less than the evidence. We drive the legacy and modernised screens and compare what a user actually gets.

  • WCF and Entity Framework

    Microsoft: Yes

    Skills cover server-side WCF to CoreWCF, EF6 Code-First and EDMX to EF Core, and LINQ to SQL to EF Core.

    Artrilogic: Yes, with contract and data proof

    Service contracts and query results are compared against the legacy system rather than assumed correct because the build passed.

Validation

  • Build and test validation

    Microsoft: Yes

    Validates the build after each change, and a dedicated skill can generate behaviour-locking tests before an upgrade begins.

    Artrilogic: Treated as the floor

    A clean build and green tests start the acceptance conversation. They do not finish it.

  • Runtime environment recreation

    Microsoft: Not a primary focus

    Containerisation and infrastructure-as-code generation are oriented towards deploying the modernised application to Azure.

    Artrilogic: Core capability

    Isolated mission environments stand up the databases, caches, brokers, test data and browsers a legacy system needs before anything is judged.

  • API and browser behavioural comparison

    Microsoft: Not a stated focus

    The documented validation model is build, test and security scanning rather than legacy-to-modern behavioural equivalence.

    Artrilogic: Core capability

    The same request and the same workflow are run against both systems, and the responses and resulting state are compared.

  • Security validation

    Microsoft: Yes

    The modernization agent scans for known vulnerabilities during execution and can apply fixes as part of the run.

    Artrilogic: An acceptance gate

    Security findings are one of the evidence types a modernisation has to satisfy before it is accepted, not a step that can be deferred.

Scale, governance and execution architecture

  • Single repository modernisation

    Microsoft: Primary focus

    The upgrade agent works on the solution in front of the developer, in the IDE or from the CLI, against a local Git repository.

    Artrilogic: Supported

    When this is the whole problem we will say so, and the right answer is often Microsoft's tooling and a good engineer.

  • Multi-repository orchestration

    Microsoft: Supported

    The Modernize CLI assesses and upgrades multiple repositories in parallel, with batch operations and CI/CD integration.

    Artrilogic: Core capability

    Orchestration also covers work that has no repository: data migrations, environment changes, integration cutovers and business validation.

  • Model and provider choice

    Microsoft: Copilot ecosystem

    Runs against the models available through the customer's GitHub Copilot subscription and development environment.

    Artrilogic: Provider agnostic

    Commercial models, open-weight models, deterministic Roslyn transforms and Microsoft's own agents, chosen per task.

  • Private or on-premises execution

    Microsoft: Requires a Copilot subscription

    Microsoft states that the agent never stores your codebase, does not train on it, and deletes session data once an upgrade completes.

    Artrilogic: Supported

    Where sovereignty, regulation or IP policy requires it, the whole workflow can run on customer-controlled infrastructure with private inference.

  • Knowledge carried between systems

    Microsoft: Repository-oriented

    Decisions persist in the repository's upgrade folder, and organisations can encode standards as reusable custom skills.

    Artrilogic: Core capability

    Patterns and validated remediations are captured against the estate, with the evidence that proved them, and offered to the next system.

  • Modernisation governance

    Microsoft: Developer and pipeline workflow

    Progress is visible through generated Markdown, commits, dashboards and pipeline runs.

    Artrilogic: Estate-level control plane

    One place to see what is in flight, what passed which gate, what evidence exists, and what the programme should do next.

Two Microsoft products are covered here: GitHub Copilot upgrade, the .NET upgrade agent for Visual Studio, VS Code, the Copilot CLI and GitHub.com, and GitHub Copilot modernization, the Azure-facing modernization agent delivered through the Modernize CLI. Sources are listed at the foot of this page.

How the approach works

One control plane. Multiple modernisation capabilities.

Artrilogic is not a single AI model. It is the layer that decides what needs to change, routes each piece of work to the capability best suited to it, and then proves the result independently.

Artrilogic modernisation control planeDecides what changes, in what order, using which capability
Microsoft toolingUpgrade agent and Modernize CLI
Frontier modelsReasoning over intent
Private local modelsInside the customer boundary
Roslyn transformations
Browser and API probes
Security analysis
Independent validationRun against the system, not against the diff
Evidence gateAccept or send back
The control plane selects an execution capability for each piece of work, then validates the result independently of whatever produced it.

Microsoft’s tooling sits here as a first-class executor. So do frontier models, private local models, deterministic Roslyn transformations, our own validated modernisation skills, and the senior engineer who should be making the call that none of them should make.

Different modernisation problems benefit from different tools. Artrilogic coordinates the execution and independently validates the result.

The value is not in forcing every problem through one model. It is in knowing what must change, selecting the appropriate capability, and proving the outcome.

Best tool for the task, chosen per mission.

Mission: modernise legacy authenticationOne unit of work in the plan
Analyse technology and dependenciesWhat is it, what touches it, what proves it still works
  • Microsoft upgrade agentFramework and dependency upgrades it already handles well
  • Commercial frontier modelsAmbiguous refactors that need reasoning about intent
  • Private local modelsCode that is not permitted to leave the customer boundary
  • Roslyn transformationsMechanical, repeatable changes that should be deterministic
  • Artrilogic skillsPatterns already validated elsewhere in the estate
  • A senior engineerThe decisions that should not be delegated to a tool
Execute
Independent validationThe executor does not get to mark its own work
Executor selection for a single mission: analyse the technology and its dependencies, choose the capability that fits, execute, then validate independently.
Environment orchestration

Modernisation happens inside a system, not inside a source file.

Legacy applications depend on their environment. A migration that cannot be stood up cannot be trusted, no matter how clean the diff looks.

Code can compile successfully and still fail as a system.

  • Provision the services the application actually needs
  • Run setup scripts and initialise databases
  • Seed representative test data
  • Control networking and restrict outbound access
  • Run the legacy and modern systems side by side
  • Execute the tests, then tear the environment down
Modernisation missionScoped, sequenced, owned

Isolated environment

  • Application
  • SQL Server
  • PostgreSQL
  • Redis
  • RabbitMQ
  • Dependent APIs
  • Seeded test data
  • Headless browser

Networking controlled, outbound access restricted, legacy and modern systems able to run side by side, torn down when the mission closes.

A mission environment stands up the services a legacy system actually needs, runs the work inside it, then tears the environment down.
Validation is the product

Modernisation is complete when behaviour is proven.

We use evidence-based acceptance gates. A modernised system is assessed against several independent forms of proof, agreed before the work starts, and the evidence stays attached to the change.

Modernised systemRunning in its mission environment
  • CompilationThe build is clean on the target framework.
  • Automated testsUnit and integration suites pass, including behaviour-locking tests written before the change.
  • API behaviourLegacy and modern endpoints answer the same requests the same way.
  • Browser behaviourReal workflows are driven through the UI and compared, not sampled by hand.
  • Data behaviourThe same operation leaves the database in the same state.
  • Security postureKnown vulnerabilities, dependency risk and configuration exposure are checked.
  • Runtime behaviourThe system starts, holds load, and behaves under its real dependencies.
  • Business acceptanceThe criteria the owning team said would make this safe to release.
Acceptance gateAssessed against criteria agreed before the work started
AcceptedEvidence retained with the change
Sent backWith the specific evidence that failed
Evidence-based acceptance: several independent forms of proof are gathered, and the gate either accepts the change or sends it back with the failing evidence attached.

A successful build tells us the code compiles. It does not tell us the business still works.

Preserve behaviour. Change the technology underneath it.

In most legacy estates the documentation is incomplete and the running system is the specification. So we treat the legacy system as the reference implementation: same request, same workflow, both systems, compared.

Where behaviour is deliberately changing, that becomes an explicit decision with a named owner, rather than a difference somebody notices in production four months later.

Request level

Legacy system

Request A
Response X

Modern system

Request A
Response X

Compared, not assumed

Workflow level

Legacy system

Workflow B
State Y

Modern system

Workflow B
State Y

Compared, not assumed

The same request and the same workflow are run against both systems, and the response and the resulting state are compared.
Compounding returns

Every modernisation should make the next one easier.

Once a pattern has been encountered and a remediation has been validated, it becomes reusable. That is the difference between doing a migration forty times and doing it once, well, forty times over.

Patterns worth capturing

  • System.Web dependencies
  • Custom HttpModules and handlers
  • Forms authentication and membership providers
  • ViewState-dependent screens
  • EF6 behaviours that EF Core does not reproduce
  • Stored procedures with business logic inside them
  • Shared internal packages with no owner
  • Configuration that only exists on one server

The objective is not for an AI model to remember your code. It is to build an explicit, auditable body of modernisation knowledge your own engineers can read, challenge and own.

System AFirst encounter with the pattern
Remediation validatedProven by evidence, not by opinion
Estate knowledgeExplicit, auditable, reviewable by your engineers
System BSame pattern, less work
System CSame pattern, less work
System DSame pattern, less work
A pattern found in one system, once remediated and proven, becomes reusable knowledge for every other system that shares it.
Customer environmentNetwork boundary the code never leaves
Source and repositories
Databases and test data
Build tooling
Mission environments
Artrilogic orchestration, deployed in placeSame control plane, customer-controlled infrastructure
Private inferenceOpen-weight models running locally
A private deployment: source, data, build and test all stay inside the customer environment, with inference running on infrastructure the customer controls.
Deployment architecture

Modernisation where your source code lives.

For organisations with regulatory, sovereignty or intellectual-property constraints, modernisation workflows can be executed inside controlled customer environments using private inference infrastructure.

This is a question of deployment architecture and control, not a claim about anyone else’s security. Microsoft states that its agent does not store your codebase or train on it. Some organisations still have a policy, a regulator or a contract that says processing must happen inside their own boundary, and that policy is the constraint we design for.

Where organisational policy permits, GitHub and Microsoft services can still be used within the same programme. It is not an either-or choice.

How Private AI worksSecure AI .NET migration
Ecosystem position

We do not replace the Microsoft ecosystem. We orchestrate around it.

Microsoft provides some of the best tooling available to .NET developers, and .NET is one of our core technology ecosystems. We are not competing with it, and we are not competing with Copilot as a coding assistant.

We build on that ecosystem and add the coordination required when modernisation extends beyond a single project.

  • .NET
  • GitHub
  • GitHub Copilot
  • Azure
  • SQL Server
  • Roslyn
  • Containers
  • Browser automation
Honest scoping

Sometimes an application upgrade is all you need.

We would rather tell you that than sell you a programme you do not have a problem for.

Microsoft’s tooling is likely enough when
  • The application is reasonably self-contained.
  • Dependencies are understood and documented.
  • Automated test coverage is good enough to catch a regression.
  • One team owns the whole application.
  • The work is mostly framework and package driven.
  • Repository-level modernisation genuinely finishes the job.

In that situation, buy the Copilot subscription, give it to a good engineer, and keep your money.

Artrilogic earns its place when
  • Dozens or hundreds of repositories, with no map of how they relate.
  • Shared databases and shared libraries that several systems depend on.
  • Behaviour that is undocumented, so the running system is the specification.
  • Several generations of .NET in production at the same time.
  • Business-critical workflows that cannot be regression tested by hand at any sensible cost.
  • Environment dependencies that make a legacy system hard to even stand up.
  • Multiple teams or vendors who each hold part of the picture.
  • Regulatory, sovereignty or IP constraints on where code and data may be processed.

At that point the transformation is the easy part, and sequencing, environments, validation and governance are the work.

At estate scale

From project upgrade to modernisation factory.

Discover, map, plan and prioritise once. Then run the same governed loop system by system, with each pass feeding what it learned back into the next.

Application estate
Discover
Map
Plan
Prioritise

Modernise, one system at a time

  • ExecuteBest executor for the task
  • ValidateIndependently, against evidence
  • LearnCapture what is now known
Next systemThe loop repeats, and it knows more than it did last time
The estate loop: discover, map, plan and prioritise once, then run modernise, validate and learn per system until the estate is done.
In one screen

The summary for the people funding it.

Microsoft

Modernisation capability

Powerful developer tooling for assessing and transforming .NET applications, now extending into multi-repository batch execution and Azure migration.

Artrilogic

Modernisation orchestration

Coordinates applications, repositories, environments, dependencies and validation, and proves behaviour survived the change.

Together

Industrialised modernisation

The best available transformation capability, running inside a governed, repeatable, evidence-producing modernisation process.

Where to start

Do not start with the framework. Start with the estate.

Before deciding what to rewrite, re-platform or upgrade, understand how the systems fit together and what business behaviour has to survive the change. That is a two to three week piece of work, and it is worth doing before anyone commits a budget.

Book an estate assessmentTalk to a modernisation specialist

Microsoft modernisation references

Statements on this page about Microsoft capabilities are based on the official documentation below, reviewed in August 2026. Microsoft ships changes quickly, so check the source if a detail matters to a decision you are making.

Microsoft, .NET, Azure, SQL Server, Visual Studio, GitHub and GitHub Copilot are trademarks of their respective owners. They are referenced here to describe the tooling accurately, and this page is not affiliated with or endorsed by Microsoft.