THE BRAINTREE APPROACH
Upgrade in place or re-architect.
There is no one-click modernisation. The right move depends on whether the problem is an ageing runtime or the way the application is built. Braintree tests the approach in the codebase before making the larger commitment.
01
Upgrade in place
Use this route when the application still fits the business but its framework or runtime needs attention. Review dependencies, supported upgrade paths and security issues. Keep the architecture where it still serves the work, and validate the changes through builds, tests and human review.
02
Re-architect
Consider a wider redesign when the architecture itself restricts scale, creates excessive operating cost or blocks a needed capability. Assess the Azure target against the workload and business case. Containers, services and new automation need a reason to be there.
03
Keep the decision human
Experienced engineers review the changes and own the release decision. Sometimes the assessment shows an application is doing its job. Braintree can leave it alone and focus the work where change matters.
SERVICE SCOPE
What’s in scope.
01
Application and dependency assessment
Review the current runtime, framework, libraries, integrations and deployment process. Identify the constraints that affect maintenance, security, release confidence or hosting cost, and distinguish an infrastructure move from a change to the application itself.
02
Runtime and framework updates
Evaluate an update to a supported .NET or Java platform where the existing architecture remains suitable. The work can include dependency changes, build fixes and compatibility testing, with the actual change set reviewed against the application’s requirements.
03
Architecture and Azure fit
Compare a managed application platform, container-based deployment or a more substantial redesign where appropriate. Choose the Azure target around application behaviour, dependencies, team capability and operating complexity, rather than selecting a service before assessment.
04
Assisted engineering with review
GitHub Copilot modernisation capabilities can support assessment, planning and code changes where supported. Braintree’s published approach keeps the output reviewable: engineers inspect changes, run tests and validate behaviour before a deployment decision.
05
Release and operational readiness
Connect the application change to environment configuration, security, observability and deployment. Record what must be tested, how production acceptance works and which team owns the modernised application after the project.
Prove the route in the codebase.
A bounded application assessment should reduce uncertainty about the proposed approach. The useful result is a reviewable engineering decision, with evidence about what can change safely and what needs further investigation.
✓
Runtime, framework and dependency findings.
✓
An update-in-place or re-architecture recommendation with assumptions.
✓
Representative code changes and a validation plan where access permits.
✓
A delivery backlog covering application, infrastructure and operational dependencies.
01
Expose the constraint in the application itself
An ageing .NET or Java application may still deliver an important business function while becoming difficult to patch, release or integrate. The right question is which part is constraining the business: the runtime, an unsupported library, deployment practices, data access or the architecture itself. A cloud destination alone does not answer that question.
Microsoft distinguishes estate discovery from code-level application assessment. Reviewing a virtual machine can reveal infrastructure and hosting characteristics; reviewing the repository exposes framework and dependency work. Braintree’s engineering scope should identify which evidence it can obtain and how that evidence supports a platform update, replatforming or a deeper redesign.
02
Access and validation required from the application team
Prepare the repository, build instructions, dependency manifests, runtime versions and deployment configuration through an approved access process. Include representative integrations, data-access patterns and the business journeys that must continue to work. If the application cannot be built reproducibly, record that as a delivery dependency rather than assuming automated changes will compile and deploy.
A useful bounded proof demonstrates the selected change against meaningful tests and records unresolved incompatibilities. The customer’s application owner remains responsible for accepting business behaviour and coordinating third-party dependencies. Agree the code-review process, test environment and ownership of resulting code. Production deployment, data migration and ongoing maintenance should be explicit in the delivery scope rather than inferred from an assessment or generated code sample.
03
Technical choices the review should resolve
Decision
Evidence to examine
What to agree
Runtime update
Framework support, dependency compatibility and a reproducible build.
Which changes can remain within the current application structure.
Platform change
State, file storage, identity, networking and deployment constraints.
The target service and the changes needed to operate there.
Architectural redesign
Business bottlenecks and the cost of preserving existing boundaries.
A justified scope, acceptance tests and the sequence of dependent changes.
BEFORE YOU DECIDE
Practical questions.
▸
Does Copilot replace code ownership?
▸
Is Kubernetes required?
▸
How is source code handled?
▸
What if the application has few automated tests?
▸
Does code assessment require a production database?
▸
Can an unsupported third-party component block the route?
▸
Is a successful build enough to approve the change?
BUILD YOUR BUSINESS CASE
Decide what to improve before deciding what to rebuild.
The problem to solve.
Old runtimes and tightly coupled applications can make every release expensive. Replacing everything at once can add risk without resolving the real constraint.
What success should look like.
Choose an upgrade or re-architecture path based on dependencies, supportability and a small proof that your team can review.
Bring these into the discussion.
A useful starting point for your team and the people approving the investment.
Useful reading for your proposal.
Evidence, examples and questions to take into the decision.
Insight
20 August 2026
Architecture decisions
Check identity when the hosting model changes
Use an App Service example to examine dependencies beyond the source code.
Read the insight
Insight
25 August 2026
Application lifecycle
Make runtime support an owned decision
Map retirement notices to the team able to plan and test an upgrade.
Read the insight
Insight
25 August 2026
Data platform lifecycle
Put database support into the modernisation case
Review the connection between version decisions, support and operating cost.
Read the insight
LET’S GROW.
Work through the next step with Braintree.
Bring one representative application. We can help scope a proof that informs the wider modernisation decision.
