Get in Touch
The .NET Framework Scope Method Coverage Runtimes FAQ
Scope Method Coverage Runtimes FAQ
About Us
AI Solutions overview AI Consulting Services AI Strategy and Readiness Enterprise AI Implementation Generative AI Consulting Agentic AI Consulting AI Automation AI Integration
Oracle Services overview Oracle Fusion Cloud Oracle Fusion Financials Oracle Fusion HCM Oracle Fusion SCM Oracle Fusion Project Oracle Sales Cloud Oracle EPM Planning and Budgeting Oracle Hyperion Financial Accounting Hub Oracle BI Integration Oracle Technology Oracle SOA Suite Oracle DBA Oracle APEX Oracle OIC Oracle VBCS Oracle E-Business Suite EBS Upgrade and Support EBS Migration to Cloud Oracle NetSuite NetSuite SuiteScript NetSuite CRM NetSuite Supply Chain, Inventory & Manufacturing NetSuite HCM NetSuite Analytics & AI
Salesforce overview Salesforce Implementation Salesforce Integration Salesforce Managed Services Agentforce and Salesforce AI Salesforce Migration
Microsoft Enterprise Services overview Microsoft Dynamics 365 F&O Microsoft Business Central Microsoft Power BI The .NET Framework
Application Management overview Java Development Mobility Solutions Android App Development React Native Xamarin Universal Windows Platform Automation Testing Services Katalon Selenium DevOps Web Development LAMP Stack MEAN Stack E-commerce Solutions Enterprise E-commerce
Managed IT Services overview Infrastructure Monitoring Network Support End User Support System Support Managed Cloud Services Managed Security Services
Managed Business Services overview Logistics BPO Services Finance and Accounting Services Healthcare BPO Services Mortgage Loan Processing Order Processing
AtomicRoute Enterprise AI Atomic HR
Manufacturing Government and Non-profit IT Services and Networks Education Real Estate Media Logistics Pharmaceutical
Insights Newsroom Gallery Why AtomicNorth Get in Touch

Custom code
only where it pays

Line-of-business applications, APIs and the integrations between them on modern .NET, plus migration off .NET Framework 4.x and the runtimes that no longer receive fixes.

Where a packaged product covers the requirement, the assessment says so and prices it against the custom option, including when that product is not a Microsoft one.

Get in touch See the delivery method
RuntimeModern .NET

New work targets a supported release with a published support end date, not the framework the last developer happened to know.

ScopeApplications and interfaces

The application, the APIs around it, and the pipeline that ships it, quoted and delivered together.

LegacyMigration before rewrite

Most .NET Framework estates move in stages behind a working system rather than in one attempt at a fresh start.

Build or buyCosted both ways

The assessment prices the packaged option alongside the custom one, even when that costs us the larger project.

What we deliver

Applications, interfaces and the migration behind them

Custom software is the most expensive way to solve a problem a product already solves, and the cheapest way to solve one no product solves properly. The assessment exists to establish which of those you have.

Line-of-business applications

Internal applications on ASP.NET Core and Blazor with SQL Server behind them: the processes currently held together by spreadsheets, shared mailboxes and one person who knows the sequence.

The data model and the ownership of each record are designed before the screens, because a screen list produces software that documents the existing mess faithfully.

A process that survives the person who currently runs it.

APIs and integrations

REST APIs with versioning, authentication and published documentation, plus the messaging, queues and scheduled work that move data between Dynamics 365, Oracle, the plants and third parties.

Interfaces are built idempotent, replayable and reconciled at cycle end, so a failed run is a rerun rather than an investigation into what half happened.

Interfaces that fail loudly and recover cleanly.

Migration off .NET Framework

Assessment of each application against a supported .NET release, dependency analysis, and a staged port that keeps the current system serving users throughout.

Components move behind the running application rather than in a parallel rewrite, because a rewrite that runs alongside the business for a year is where these programmes fail.

A supported runtime reached without a freeze on new work.

Runtime and dependency currency

An inventory of every application with its target framework, its libraries, its database version and the support end date of each, kept current rather than produced once.

Third-party components are the part that stalls migrations, so their status is established at the start instead of discovered midway through.

A dated list of what expires next, and what it will take.

Pipelines, testing and environments

Source control, build and release pipelines, automated tests written alongside the code, and environments that can be rebuilt from configuration rather than remembered.

Tests exist so a dependency update is a routine change. Without them, every upgrade becomes a project and the estate quietly stops being upgraded.

An upgrade that is a release rather than a programme.

Support, documentation and handover

Application support after go-live: fixes, dependency updates, releases, and documentation written for the next team rather than for the current one.

Code, pipelines and documentation sit in your repositories from the first commit. Being replaceable is part of the design rather than a risk we manage.

Custom software with a maintenance story attached.

How a .NET engagement runs

StageOneAssess

The outcome in business terms first, then the honest options: configure something you already own, buy a packaged product, extend an existing platform, or build.

A surprising share of requests for custom software are met by a product already licensed elsewhere in the estate. That answer is cheaper for you and smaller for us, and we still give it.

You receive:

A costed options paper

Each option with its build effort, its licence implication, its support burden and its exit cost, side by side rather than in sequence.

Yours to keep whether or not anything gets built.

StageTwoDesign

The data model, the ownership of each record, the integration contracts, the identity and access design, and the non-functional requirements somebody will eventually be measured on.

For a migration this is where the target runtime, the staging order and the dependency replacements are fixed, so the port has a sequence rather than a direction.

You receive:

A design and a sequence

Data model, interface contracts, hosting and identity design, test strategy, and a phase order with a working system at the end of each phase.

Anything deferred is written down as a decision with an owner rather than left as an assumption.

StageThreeBuild

Working software each sprint in an environment your team can open, with pipelines, automated tests and code review from the first commit rather than added before go-live.

Interfaces are tested by failing them deliberately, because that behaviour is otherwise discovered in production by an accountant at month end.

You receive:

A tested release

Software in an environment you control, automated regression over the critical paths, migration rehearsed against real data, and a cutover runbook with rollback points.

Go or no-go criteria agreed before testing starts, so the decision at the end is arithmetic.

StageFourRun

Steady state: fixes, dependency updates on a cycle, framework upgrades planned against support end dates, and releases through the same pipeline that built the system.

Applications rot at the edges. The libraries age, the runtime reaches end of support, and the estate that skipped this cadence is the one facing a rewrite.

You receive:

A monthly service review

Incidents and fixes, dependency and framework position against published support dates, release record, and the plan for whatever was deferred.

Documentation updated as part of each release rather than as an annual exercise nobody funds.

01
Coverage

What sits in the .NET practice

Delivered as a project, a managed service, or a project that converts into application support at go-live.

The .NET Framework coverage
AreaScopeWhere it usually startsModel
Line-of-business apps ASP.NET Core, Blazor, worker services, SQL ServerA process running on spreadsheets and a shared mailboxProject then managed
APIs REST APIs, authentication, versioning, documentationTwo systems joined by a nightly file nobody ownsProject or managed
Integration Messaging, queues, scheduled work, reconciliationInterfaces that fail quietly and surface at month endProject or managed
Migration .NET Framework 4.x to a supported .NET releaseA platform with no remaining support pathProject
Hosting and identity Azure App Service, containers, single sign-onAn application on a server nobody wants to patchProject or managed
Application support Fixes, dependency updates, releases, documentationA system whose original developer has leftManaged
Runtimes

An unsupported runtime is a dated risk

A .NET Framework 4.x application does not stop working on the day support ends. It stops receiving fixes, which means the next issue in the platform underneath it becomes your problem, and the estate loses the ability to accept a security update without a rebuild.

So the work starts with a dated inventory rather than a rewrite proposal: every application, its target framework, its dependencies, and the support end date attached to each. Most estates then need a staged port and a dependency clean-up. Very few need a fresh start.

Ask for a runtime review
  • Dated inventoryEvery application with its framework, its libraries, its database version and the support end date of each, so the next decision arrives with a deadline attached.
  • Ported in stagesComponents move behind a working system, one at a time, rather than in a parallel rewrite that runs alongside the business until somebody cancels it.
  • Rewrites resistedA rewrite is proposed only where the existing code genuinely cannot be moved. It is the expensive answer, and it is offered last rather than first.

Indicative practice. Sequencing and effort are set after the runtime review.

Questions we get asked

Before building anything custom

Should we migrate or rewrite?

Migrate, in almost every case. A rewrite discards working business logic that nobody has documented, and it competes with the existing system for the same users and the same budget until one of them is abandoned. Rewriting is the right answer when the current code cannot be ported at all, and that is rarer than the people proposing it suggest.

Why would you tell us to buy a product instead of building?

Because the alternative is a system we build, you pay to maintain, and neither of us can defend in three years. Where a packaged product covers the requirement, saying so early costs us one project and keeps the relationship. We will also say when the product is not a Microsoft one, since the assessment is about your requirement rather than our partner status.

Power Apps or .NET for a new internal application?

Power Apps where the process is forms, approvals and data that already sits in Dataverse or Microsoft 365, which covers a real share of internal tooling. .NET where the logic is genuinely complex, the performance profile is demanding, or the application faces customers. Choosing low code for the wrong problem produces something nobody can maintain, and so does choosing custom code for a form.

Can you support an application you did not build?

Yes, and it is a common starting point. The first work is reading the code, mapping the dependencies and documenting the deployment, because that documentation has usually left with the person who wrote it. Once that exists, the application becomes supportable by a team rather than by one individual, which is normally the actual problem.

Can you work alongside our own developers?

Routinely. The usual arrangement is a shared repository, shared pipelines, shared code review standards and one backlog, with the boundary drawn around components rather than around tasks. What does not work is two teams owning the same component with no agreed review, and we will say so rather than accept the structure and bill for the friction.

Software with amaintenance story.

Start with a costed options paper or a runtime review. Both are short, both produce a document you keep, and neither commits you to building anything.

Get in touch Book a scoping call