Your order entry application still does its job. Staff know the screens, customer pricing is correct, and the warehouse gets its picking lists. But a server needs replacing, a vendor has stopped updating a component, or every small change now requires finding the one person who knows how to deploy it.
That is a reason to investigate the application. It is too early to price a complete rebuild.
.NET Framework modernization can include updating the existing platform, replacing unsupported dependencies, improving deployment and testing, and moving selected components to modern .NET. Before rebuilding a business app, establish what is unsupported, what is causing trouble, and which parts still serve the business well.
I would start with the work the application needs to keep doing, then decide how much software has to change.
Is .NET Framework still supported?
Some versions are. .NET Framework 4.8 and 4.8.1 remain supported on qualifying Windows versions, subject to Microsoft's lifecycle and servicing requirements. The Windows version matters, and individual libraries and third-party products have their own support policies. An application does not become unsupported simply because its name includes .NET Framework.
There are also two different upgrades to consider. Updating an application within .NET Framework, such as moving to a compatible 4.8 or 4.8.1 target, is different from migrating it to modern .NET. Modern .NET, previously called .NET Core, has different project requirements, APIs, and release lifecycles.
Check the framework the source code targets, the runtime installed on each server or workstation, the Windows version, the database platform, and the components supplied by other vendors. A supported runtime does little to help an abandoned reporting control or an operating system that has reached the end of its support.
Choose a supported destination that works with the actual environment. Installing 4.8.1 everywhere is not a plan if some of those machines cannot run it. A move to modern .NET also needs enough support remaining on the selected release to cover development, rollout, and ongoing use.
Make sure you can build, deploy, and recover the current app
Before changing much code, have someone build the application from a clean checkout in a separate environment. That exercise often reveals missing packages, licensed controls, old build tools, undocumented settings, and files that exist only on a developer's computer.
Then deploy that build to a test environment and walk through a real task. Confirm how configuration, certificates, service accounts, scheduled jobs, and database changes reach each environment. A successful compilation leaves a lot of operational questions unanswered.
Recovery deserves the same attention. Check that the business has the source code and access it needs, document the release process, and test the relevant backups and restores. Where keys or certificates protect stored information, include their recovery requirements too.
These improvements are useful even if the larger migration waits. They also make application support and maintenance less dependent on somebody remembering what happened during the last release.
Capture the business rules before moving them
Consider a hypothetical wholesale distributor. Its application accepts orders, applies customer discounts, checks credit holds, prints warehouse documents, and sends approved invoices to accounting overnight.
The order form may contain rules nobody calls requirements anymore. A particular customer gets different freight terms. A supervisor can release an order on hold, but the decision must be recorded. A price changes according to the delivery date rather than the date the order was entered.
Those rules can live in screen events, shared libraries, stored procedures, database triggers, and overnight jobs. Ask the people doing the work to demonstrate ordinary orders and exceptions, then trace where the software enforces each decision. Include the spreadsheet or manual correction that fills a gap in the current process.
Turn the important examples into repeatable checks before refactoring. Record the inputs, expected decisions, calculations, permissions, and resulting documents. QA and test automation can preserve stable behavior through later changes, while employees review whether the results still make business sense.
An existing result may be wrong. If you find a pricing defect during this work, agree on the corrected behavior explicitly. Quietly changing a calculation while migrating it makes disagreements harder to diagnose.
Find the dependencies that will determine the migration
An old application may use a grid control, PDF generator, report viewer, database driver, or connection to a desktop product. Check which versions are installed, whether licenses and installers are available, and whether the vendor supports the intended destination.
Some libraries can move with limited changes. Others need replacing. A Windows-specific component may remain usable on modern .NET while still requiring Windows. Changing the runtime does not automatically make an application suitable for Linux or a browser.
Test the difficult dependencies early. If the distributor's warehouse documents rely on a discontinued report designer and a particular printer, produce a representative picking list on the proposed platform before rebuilding the order screens. Check page breaks, labels, quantities, fonts, and printer behavior with the warehouse team.
Prioritize dependencies by support risk and the work they affect. Updating every package to its newest version in one release can combine unrelated changes and make failures harder to isolate. A smaller, tested sequence gives the team a better chance of knowing what caused a problem.
Check the database and reports before blaming the framework
A slow order search might be caused by an inefficient query, missing index, excessive data transfer, or blocking between users. Measure the actual request and database activity before assuming a new runtime will fix it.
You can often retain a useful database while modernizing the application around it. Review the database platform's support status, drivers, permissions, and backup process, then decide which schema changes the migration actually needs. Moving from Entity Framework 6 to Entity Framework Core, if proposed, is a separate compatibility task that can change queries and behavior.
For the distributor, compare customer balances, order totals, tax and freight calculations, and the accounting export using representative records. Reports may depend on stored procedures or scheduled processes that never appear in the visible application. Include those in the inventory.
Where records need cleaning or moving, scope that as data migration work, with reconciliation and a rehearsal. Our business data migration cost guide explains why validation and cutover can take more effort than copying the rows.
If staff also need better management information, reporting and dashboards can be a separate phase. Keep the required operational reports working while deciding what should improve.
Review sign-in, permissions, and system connections
Authentication can become a substantial part of an ASP.NET Framework to ASP.NET Core migration. Existing Windows authentication, forms authentication, session handling, and user permissions need an explicit design for the new application and any period when both versions operate together.
Start with what each person is allowed to do. An order clerk, warehouse worker, and credit supervisor may all open the same order while having different rights to change it. Verify those rights on the server, including direct requests, exports, and attachments. Test rejected actions alongside successful ones.
Connections outside the application need their own review. Find the accounting export, supplier feed, email process, shared folder, Windows service, and scheduled task. Record who owns each connection, which credentials it uses, and how the office learns about a failure. Systems integration belongs in the modernization estimate when those handoffs change.
In the distributor example, a retry must not create the same invoice twice. A failed overnight export needs a visible status and a controlled way to resume. Replacing the order screen while leaving that failure unresolved would do little for the person reconciling invoices the next morning.
Can you move to modern .NET without rebuilding the screens?
Sometimes. Windows Forms and WPF are available on modern .NET and remain Windows technologies. A desktop application may be able to retain much of its interface while its projects, libraries, and incompatible APIs are updated. Third-party controls and device dependencies still need testing.
ASP.NET applications require a different assessment. ASP.NET Web Forms does not run on ASP.NET Core. Its pages and controls need a different implementation for that destination, although suitable business logic and data access code may be reusable. ASP.NET MVC and Web API applications also need review for System.Web, authentication, configuration, and other framework differences.
Keep the business reason for a new interface clear. If employees need browser access from several locations, that may justify web application development. If the desktop workflow is effective and depends on local equipment, preserving it could be the more practical first phase.
A library or background process can sometimes move before the interface. For a larger web application, old and new routes may run alongside each other while individual workflows migrate. That requires deliberate handling of sign-in, session state, routing, and data ownership. It also needs an end point, so the business does not pay to maintain two applications indefinitely.
Prove one complete workflow before a wider rollout
For the distributor, I would choose a first release that can handle an order through the required handoffs: entry, pricing, approval, warehouse output, and accounting transfer. A polished screen with an unfinished export cannot take over that job.
Use representative records and workload, including credit holds, cancelled orders, changed quantities, and two people editing the same order. Compare important outputs with the current application and investigate differences. Keep customer emails and accounting submissions controlled during parallel testing so the comparison does not trigger duplicate actions.
If the old and new applications share a database, specify which one can change each type of record. Database changes must also remain compatible with whichever components are still running. A pilot group needs clear instructions about where to enter work and where to find it afterward.
Plan the way back before the switch. Returning to the old application may also require reconciling orders entered after the new version went live. Restoring an earlier database could erase valid work. Agree on the conditions for stopping the rollout, who can make that decision, and how new records will be preserved.
Our guide to modernizing legacy software without interrupting daily operations covers phased rollout and cutover in more detail.
When is a rebuild worth considering?
A rebuild can make sense when the workflow itself needs substantial change, essential components have no workable upgrade path, or the existing architecture makes necessary improvements too difficult to support. Missing source code or an application that cannot be reproduced can also change the available options.
Ask for evidence behind that recommendation. Which parts cannot be retained? What would a smaller upgrade accomplish? What business improvement pays for replacing the interface, migrating the data, and retraining staff?
Compare the scope of a supported upgrade, a phased migration, and a replacement. Include development, licenses, hosting, testing, training, temporary operation of both systems, and continuing maintenance. Our custom software development cost guide covers the factors that make screen count alone a poor basis for an estimate.
Before requesting that estimate, gather the application's known versions, source availability, critical reports, connected systems, and recurring problems. A useful software discovery phase should turn that information into a dependency inventory, tested findings, and a proposed sequence of work.
Honor Tech develops and supports custom web, mobile, and Windows applications. A workflow and integration assessment can establish what your existing .NET application does, what needs attention first, and which improvements justify a larger migration. Tell us what the application runs and where it is getting difficult to maintain.