Procure-to-Pay Application Modernization for a Global Hospitality Organization

Modernizing a Legacy Classic ASP and Oracle Platform with React, .NET Microservices, AWS, and Intelligent Automation

A global hospitality organization relied on a long-running procure-to-pay platform supporting purchasing, purchase orders, invoicing, receiving, financial workflows, supplier interactions, and customer-facing business processes.

The application contained years of valuable business logic, but its legacy Classic ASP and Oracle architecture made continued enhancement increasingly difficult.

Stackular modernized the platform using a React frontend, .NET microservices and APIs, and AWS cloud architecture, while preserving the business capabilities the organization depended on.

The modernization also created the foundation for new automation capabilities, including intelligent invoice processing using Azure AI Document Intelligence, purchase-order matching, accounting recommendations, and more streamlined AP workflows.

The objective was not simply to rewrite the existing screens in newer technology. Stackular separated the user experience, application services, integrations, and business logic so the platform could continue evolving without reproducing the coupling of the legacy implementation.

The Challenge

The procure-to-pay platform was business critical.

It supported financial and operational processes that could not simply be taken offline while a replacement was developed.

At the same time, the legacy architecture created growing challenges around:

maintainability
frontend development
integrations
release complexity
automated testing
introduction of new capabilities
cloud adoption
AI and automation

Continuing to extend the Classic ASP implementation would have preserved those constraints and increased the amount of functionality eventually requiring modernization.

Stackular's Approach

Stackular treated the initiative as an application-platform modernization rather than a visual refresh.

The architecture was decomposed into clearer layers:

React for the user experience
.NET services and APIs for application logic
AWS for the target cloud architecture
Oracle integration during the modernization transition
API-based boundaries for integrations and future capabilities

This allowed individual application capabilities to evolve more independently while preserving business continuity.

Legacy starting pointClassic ASP + OracleValuable business logic constrained by aging architecture
Modern experienceReact frontendReusable interfaces, responsive workflows, and independent evolution
Business capabilities.NET services + APIsModular logic, integrations, testing, and reuse
TransitionOracle integrationBusiness continuity while components modernize incrementally
Target runtimeAWS cloud architectureHosting, scaling, deployment automation, and monitoring

Foundation for continued automationInvoice processing, matching, accounting recommendations, analytics, and future capabilities

The platform transitions from tightly coupled Classic ASP toward a React experience and reusable .NET services on AWS while Oracle integration preserves continuity during modernization.

React Frontend Modernization

The new React frontend replaced the constraints of the Classic ASP presentation layer with a component-based application architecture.

This supports:

reusable interface components
responsive experiences
clearer separation between presentation and business logic
easier testing
faster enhancement of individual application modules

The frontend can evolve without embedding business logic directly in page rendering.

.NET Microservices and APIs

Backend functionality was modernized using .NET services and APIs.

Moving business capabilities behind defined service interfaces created cleaner boundaries between the frontend, business logic, integrations, and data access.

This supports:

modular application development
independent testing
enterprise integrations
reuse of business capabilities
future automation and AI workflows

AWS Cloud Architecture

The modernized application runs using an AWS-oriented cloud architecture rather than continuing to extend the legacy hosting model.

The cloud architecture provides a more flexible foundation for application hosting, scaling, integrations, deployment automation, monitoring, and continued modernization.

The project was not treated as a simple lift-and-shift. The purpose of cloud adoption was to improve the application architecture and operating model, not merely relocate the existing servers.

Preserving Business Logic Without Preserving Legacy Coupling

One of the hardest parts of enterprise modernization is distinguishing between business rules that remain valuable and technical structures that no longer do.

The procure-to-pay platform contained important domain knowledge accumulated over years of operation.

Stackular preserved those business capabilities while redesigning how they were implemented.

That approach reduced the risk of losing valuable process knowledge while avoiding the mistake of rebuilding the same legacy architecture in newer languages.

Creating a Foundation for AP Automation

The modernized architecture also created the foundation for intelligent invoice-processing capabilities.

Azure AI Document Intelligence is used to interpret invoice documents and extract structured information.

The broader application then supports functions such as:

invoice field extraction
invoice line-item extraction
purchase-order matching
invoice-line-to-PO-line matching
GL-code recommendations
validation
exception handling

The AP automation work is documented in greater depth in the related AP Automation case study.

Key Technical Decisions

Why modernize instead of replacing the entire product with a commercial package?

The platform contained differentiated business processes and integrations that remained valuable. Modernization allowed the organization to preserve those capabilities while replacing the technical architecture that made change increasingly difficult.

Why React?

React provides a mature component model for complex enterprise web applications and allows the frontend to evolve independently from backend implementation details.

Why .NET microservices and APIs?

Defined services make business capabilities easier to reuse, test, integrate, and evolve than logic embedded inside a tightly coupled legacy application.

Why AWS?

AWS provided the target cloud foundation for hosting and operating the modernized application while supporting the broader move toward modular services and modern deployment practices.

Why retain Oracle during modernization?

Large application modernizations frequently require old and new architectures to coexist. Maintaining integration with the existing data platform allowed the application to be modernized incrementally rather than requiring a single high-risk replacement event.

Business Results

Modern Application Architecture

The organization moved from a Classic ASP-based application toward a React, .NET, API-driven, AWS architecture.

Improved Maintainability

Clearer separation between presentation, business services, integrations, and data access makes the platform easier to enhance and test.

Faster Path to New Capabilities

The modern architecture supports the introduction of automation, intelligent document processing, embedded analytics, and additional customer-facing functionality without extending the legacy architecture.

Reduced Long-Term Technical Risk

New investment is directed toward the modern platform rather than increasing dependence on Classic ASP.

Foundation for Continued Modernization

The application can be transformed incrementally while continuing to support critical procure-to-pay operations.

Technologies Used

Lessons Learned

Don't rebuild the legacy architecture in a newer language.

The value of modernization comes from improving application boundaries and delivery practices, not merely changing syntax.

Preserve business knowledge, not technical debt.

Years of operational rules may remain valuable even when the architecture implementing them no longer is.

Modernize incrementally when the application cannot stop operating.

Business-critical platforms often require coexistence between old and new components during transition.

Design APIs as reusable business capabilities.

A well-defined API layer supports web experiences, integrations, automation, analytics, and future AI use cases.

Frequently Asked Questions

What is procure-to-pay application modernization?

Procure-to-pay modernization updates the architecture and user experience of systems supporting purchasing, purchase orders, receiving, invoicing, suppliers, and related financial processes while preserving required business functionality and integrations.

Can a Classic ASP application be modernized incrementally?

Yes. A modern frontend and service layer can be introduced progressively while legacy components continue operating during transition, reducing the risk of a single large cutover.

Why use React and .NET for enterprise modernization?

React provides a component-based frontend architecture while .NET provides mature capabilities for APIs, enterprise integrations, business logic, and cloud deployment.

Does moving an application to the cloud automatically modernize it?

No. A lift-and-shift can preserve the same coupling and technical debt in a new hosting environment. Modernization should improve architecture, testing, deployment, integration boundaries, and maintainability as well as infrastructure.

How does modernization enable AI and automation?

Modern APIs, structured data, and clearer application boundaries make it easier to connect AI and automation to controlled business capabilities than in tightly coupled legacy applications.