When .NET application development fits the project
A React web application may use existing C# rules and APIs behind a new interface. The technology decision should reflect team experience, connected systems and the product’s maintenance model. An established Microsoft environment is useful context, but it does not require every new feature to use an identical architecture.
Imagine an illustrative dealer portal where a customer requests a quote and follows its status. Internally, a sales team manages pricing and approval. A new interface could support that journey without replacing the ERP that owns the commercial records. This describes a scoping scenario, not a completed Prix project.
Discovery maps users, tasks and connected systems. A new application, an extension to an existing platform and modernisation of older .NET code are different engagements. Source-code access and operating conditions help determine the approach. The first delivery should have a recognisable business outcome rather than just a list of framework features.
Keep business rules and system ownership explicit
A content-heavy site may suit headless CMS development, while prices, approvals and orders remain another application’s responsibility. Mixing those boundaries can turn an ordinary content edit into a consequential commercial change. We establish which system owns each type of information before designing the screens around it.
Define where records originate, which values can change and what becomes fixed after approval. Whether a new price should affect an old quote is a small-looking decision that changes product behaviour. Exceptions should become representative acceptance examples rather than remain buried in meeting notes.
The approach also helps separate a customer journey from internal administration. A customer may submit a request, while an operator verifies it and another person authorises the final change. Modelling that sequence avoids giving a convenient interface more authority than the organisation intends.
New business portal
Controlled customer or dealer access to existing systems. Start with the most important task and define the information that must remain owned elsewhere.
Application extension
Add a workflow or API to a working platform. Check existing consumers and record behaviour alongside the new capability.
Modernisation
Address a support, dependency or usability problem in deliberate stages. A complete rewrite should follow evidence, not the age of the interface alone.
FROM READING TO A NEXT STEP
Plan the next workflow alongside your existing system
Share the portal, API or modernisation requirement. Let’s identify what must be preserved and the first useful delivery boundary.
Define identity, roles and resource access
As with a backend development project, .NET application scope should separate a user’s identity from permission to perform an operation. Signing in must not imply access to every record. If the organisation has an existing sign-in system, its requirements should be examined early.
Access may depend on branch, team, customer organisation or record state. A sales representative could be allowed to view a request without changing an approved price. An external integration may need permissions different from a human operator. The interface should communicate the rules, and the server should enforce them.
Acceptance checks should include operations that are permitted and attempts that must be denied. Decide what happens when a role changes, a session ends or a record moves to another team. Sensitive projects may need additional security review. Choosing a framework is not the same as achieving a certification or establishing that every access path is safe.
Connect ERP, CRM and background work
When automation workflows and a .NET portal handle the same records, repeat events and failures need a shared rule. For an order, status change or report transfer, define the source, update order and owner of unsuccessful work. A successful connection test does not resolve these business decisions.
If an external system stops responding, the interface should not incorrectly report that the operation completed. Work may wait, retry within agreed boundaries or go to an operator. The consequence of the task determines the appropriate response. Preventing the same commercial action from happening twice may matter more than adding another technical log.
Background work also needs assessment during application shutdown, releases and growing workload. An in-process queue is not automatically durable storage. Critical synchronisation and large imports may need a different persistence and monitoring approach, chosen with the hosting environment and recovery requirements.
| Integration decision | Question to answer |
|---|---|
| Data ownership | Which system holds the authoritative current value? |
| Repeat operations | What happens when the same request arrives again? |
| Failure | What do the user and operations team see? |
| Long-running work | How is work protected during a release or interruption? |
Modernise older .NET applications in controlled stages
Before replacing older .NET code with a different application stack, establish the problem. An unsupported dependency, a slow query, an awkward screen and a runtime support issue need different responses. A new technology label does not automatically solve all of them.
Review the source, dependencies, data model, external consumers and release process. Build representative checks around behaviour that already works. Where a bounded area can be improved, change it within a clear interface. If old and new components run together, data consistency and the user’s route through the application need deliberate design.
A data transition needs field mapping, sample-record validation, a cutover decision and a recovery path. Do not assume zero downtime or an effortless migration. The release plan should reflect accepted risk and the organisation’s working calendar. Critical operating days are a constraint to consider, not arbitrary dates for trying the new system.
Agree production delivery and long-term responsibility
The CI/CD and DevOps setup should fit the target environment’s access and release conditions. If the application already uses IIS, a cloud service or another hosting model, explain the reason for any change. A successful local build is only one checkpoint in taking responsibility for production.
A useful handover includes source code, configuration guidance, API and data-model notes, and acceptance evidence. Environment ownership should remain clear. Identify who handles backups, log retention, alerts and runtime updates. A particular incident response time or continuous support commitment needs separate agreement rather than an implied promise on a development page.
Bring an example workflow, the known .NET version, repository access situation and connected systems to the first review. Missing information can become an inspection step instead of being filled with guesses. The initial scope should help complete a valuable task while making the dependencies and continuing responsibilities visible.
BEFORE YOU DECIDE
Frequently asked questions
Are .NET and ASP.NET Core the same thing?
ASP.NET Core is part of the .NET ecosystem used for web applications and APIs. Define the application type in scope. Desktop or mobile development is not automatically included in a web/API engagement.
Can a new application work with our Microsoft systems?
That depends on integration access, product versions, identity requirements and available provider interfaces. Review the actual systems rather than assume a ready-made connector exists for every ERP or internal platform.
Can the interface use React?
Yes, an appropriate API and access model can support that approach. Browser sessions, record permissions, error behaviour and deployment environments should be designed together, with clear frontend and backend boundaries.
Must an old .NET Framework application be completely replaced?
An assessment is needed. Working business rules may support staged improvement. Unsupported dependencies, data structure and operating constraints can affect how much change is required.
Does .NET development require Azure?
Do not assume one hosting choice. The target application, existing environment, operations team, costs and release requirements should inform deployment decisions.
How is a .NET project estimated?
Business rules, inherited code, integrations, data, permissions and acceptance needs influence the work. Screen count or the framework name alone is not enough for an accurate scope.
LET’S DEFINE THE SCOPE
Plan the next workflow alongside your existing system
Share the portal, API or modernisation requirement. Let’s identify what must be preserved and the first useful delivery boundary.
Discuss my .NET project