MICROSOFT PRODUCT CAPABILITIES
Modernise where it improves the application.
Azure offers several ways to host applications and data. The right choice depends on your code, dependencies, scaling patterns, and operational responsibilities. An application can be modernised in stages, with different components following different paths.
Azure App Service
Run supported web applications and APIs on a managed platform, with deployment and scaling capabilities suited to the selected plan.
Azure Container Apps
Run containerised applications, microservices, and jobs with managed infrastructure, revisions, and event-driven scaling.
Azure SQL Database
Use a managed database service for suitable application databases, with platform maintenance and built-in availability capabilities.
SQL Managed Instance and SQL on VMs
Choose a managed instance for broader SQL Server compatibility, or SQL Server on Azure Virtual Machines when OS and instance control are required.
Use compatibility to guide the decision
Check database features, runtime support, integrations, latency, and operational controls before selecting a service. Moving a database and redesigning an application are different pieces of work.
Put it to work with Braintree.
Braintree assesses the application, defines the target architecture, tests compatibility and performance, and moves the agreed components with deployment, monitoring, and recovery in place.
Microsoft product guidance
Modernise in an order the business can absorb
Braintree’s published approach starts with change readiness and the operational constraints of existing systems. Data improvements, API work or selected platform changes can form an initial phase without committing the entire estate to a single replacement project.
✓
Map the dependencies behind critical business processes.
✓
Choose the first change using operational value and risk.
✓
Confirm security, identity, governance and cost requirements.
✓
Define validation and rollback criteria before production changes.
01
Identify the change that has become too expensive
Modernisation is useful when keeping an application stable has begun to prevent useful change. A small feature may require several coordinated releases, reports may duplicate business rules, or an old data platform may consume disproportionate support effort. The first task is to locate the constraint and decide which change would improve the business process.
For example, an order system may still perform its core task while its reporting depends on fragile export scripts. A first phase might improve the data pipeline and reporting access without replacing order entry. That is an illustrative decision pattern: the assessment determines whether the dependency, security and cost implications make it appropriate.
02
Choose the intervention, not only the destination
Microsoft’s modernisation guidance distinguishes approaches such as replatforming, refactoring and rearchitecting. A platform move may reduce maintenance with limited code change; refactoring changes selected application internals; rearchitecting changes how components work together. Retaining or retiring a workload can also be a deliberate outcome of assessment.
The Braintree offer focuses on incremental change: decoupling components, exposing functionality through APIs, separating storage from processing and introducing managed services where they remove friction. A container is not automatically the right destination, and a managed database is not automatically compatible with every feature in an existing database. Each choice needs an application-level reason.
03
Protect the meaning of the data
Modernising a data platform includes ownership, identifiers, transformation logic and access. Moving a database without understanding which reports or integrations depend on it can preserve the technical problem in a new location. The work should identify where business rules are duplicated and which system remains authoritative.
APIs can create a clearer boundary around existing functionality, but the contract needs to be defined: allowed operations, authentication, versioning and the handling of errors. The buyer should see how a dependent application behaves when an interface is unavailable, not only how a successful request works. Those boundaries make phased replacement more manageable.
04
Validate a phase before extending it
Braintree can assess the application and data estate, agree the first intervention and sequence delivery around operational constraints. Microsoft’s execution guidance emphasises non-production development, validation and controlled deployment. Production acceptance should therefore include rollback and monitoring as well as the new feature.
Inventory applications, data stores, interfaces and the teams that depend on them.
Rank candidate changes by business value, dependency risk and operating effort.
Define a target service, integration contract and measurable acceptance criteria for the first phase.
Test performance, security, data reconciliation and rollback before changing production.
Agree operational handover and the evidence used to choose the next phase.
BEFORE YOU DECIDE
