MICROSOFT PRODUCT CAPABILITIES
Know what is moving before it moves.
Azure Migrate provides a central place to discover, assess, and move eligible workloads to Azure. It helps establish an inventory, understand dependencies, and compare a target configuration before migration tools carry out the move.
Discovery and assessment
Inventory supported servers, applications, and databases, then assess readiness, sizing, and the changes needed for Azure.
Dependencies and business case
Use workload relationships and assessment outputs to plan migration groups and compare the proposed Azure configuration with the existing estate.
Migration execution
Use supported Azure and integrated migration tools to replicate or move the selected workload, with a planned test and cutover.
Operational handover
Validate application access, performance, backup, monitoring, and ownership after the move so the environment is ready to run.
Separate migration from redesign
Some workloads can move with limited application change; others need remediation or modernisation. Discovery tooling, permissions, network requirements, and the target service determine the route.
Put it to work with Braintree.
Braintree builds the Azure foundation, groups and tests the workloads, manages cutover, and connects the migrated environment to ongoing support and cost management.
Microsoft product guidance
Prepare the destination and the operating team
Migration changes where a workload runs and how it is operated. Identity, networking, monitoring, recovery and support responsibilities need to be part of the plan alongside the movement of applications and data.
✓
Identify business owners and acceptable cutover windows.
✓
Validate data replication and application dependencies.
✓
Confirm regional service availability and data-governance requirements.
✓
Agree post-migration monitoring, support and cost ownership.
01
Migrate a working service, not just a server
A migration needs to preserve the business function performed by the workload. The server inventory is only a starting point: applications may depend on a database, identity service, file share, scheduled task or integration that somebody outside IT operates. Missing one of those dependencies can leave a technically migrated machine unable to support the business.
For example, a finance application might run correctly in a test virtual machine but still require a local document share and a connection to the bank-processing workflow. The assessment needs to identify those dependencies and decide how they will work after cutover. This is an illustrative migration risk, not a claim about the state of your environment.
02
Use discovery to choose the destination
Microsoft’s Azure Migrate service supports discovery, assessment and migration planning for supported server, database and application scenarios. Assessment can inform readiness, sizing, cost estimates and dependencies. The destination might be an Azure virtual machine, a managed database or an application platform, depending on compatibility and the intended operating model.
Measured utilisation is useful when evaluating capacity, but it needs a representative period and business context. A quiet week may not describe month-end or a seasonal peak. Similarly, a cost estimate must identify its assumptions about region, operating hours, resilience, licensing and support. The assessment is decision evidence rather than a promise that every workload should move.
03
Replication and validation lead to an agreed decision
The published Braintree process uses planned migration windows, validation and rollback. A useful plan states when data replication begins, how changes are controlled at cutover and who decides whether the migrated service can be accepted. The business owner needs a test that represents actual work, not only an infrastructure health check.
Rollback must be designed alongside the cutover. Once users or integrations write new transactions into the destination, returning to the source may require a data decision as well as a technical one. The proposal should make those conditions visible before migration begins and identify any workload that needs an interruption.
04
The destination needs an operating owner
Braintree can assess the estate, define the sequence and implement the agreed migration scope. Identity, networking, monitoring, recovery and cost management must be prepared alongside the target workload. After acceptance, the team needs a documented way to run and support it.
Map applications, dependencies, business owners and required operating windows.
Choose a supported target and record sizing and cost assumptions.
Define replication, cutover, validation and rollback conditions.
Confirm permissions, regional availability, networking and data-handling requirements.
Document the accepted configuration, support responsibilities and source-retirement decision.
EVIDENCE & DOCUMENTATION
See the work in context.
BEFORE YOU DECIDE
