Before You Leap
A practical framework for assessing migration readiness before the Dynamics GP support deadline.
Executive overview
- Microsoft will end Dynamics GP product enhancements, regulatory updates and technical support on 31 December 2029. Security updates will remain available until 30 April 2031.
- The support timetable gives organisations a defined period in which to assess their GP environment and prepare the work required for migration.
- Executive approval requires a complete investment case and an agreed scope. The continuity plan must have passed testing.
- A migration roadmap must reflect the condition of the organisation’s data and integrations. It must also account for internal delivery capacity.
The deadline sets the planning period
Microsoft will end product enhancements, regulatory updates and technical support for Dynamics GP on 31 December 2029. Security updates, where required, will remain available until 30 April 2031. These dates give GP customers a defined period for assessment and preparation. The implementation date must come from evidence gathered inside the organisation.
Transaction processing offers limited evidence of the condition of the supporting environment. The assessment needs to establish whether GP knowledge rests with a small group of employees. It must check the documentation and ownership of older interfaces. It must also record any manual reports used to compensate for limitations in the system. Each condition has a cost and a direct bearing on continuity.
The executive assessment must record the current condition of the environment and the work required to replace it. That record gives management a basis for deciding when to begin implementation.
What the investment decision must include
Migration places several major costs inside one programme. The budget has to cover the software, implementation work and the preparation of data. It also needs to provide for testing, training and support after go-live. Contributions from finance and operational teams reduce the time available for other business priorities.
Continued use of GP leaves the organisation responsible for its current infrastructure and support arrangements. The business case must account for manual workarounds, older integrations and any specialist assistance required during the planning period.
The investment paper must set out the full migration expenditure and the cost of retaining GP through planning and transition. It must identify an owner for each expected benefit and state how management will measure the outcome.
Six questions for executive approval
1. Is the investment case complete?
The budget must reflect the approved scope. Licensing and implementation form part of the cost. Data preparation, integration work, testing, training and post-go-live support require separate provision.
Internal time also belongs in the calculation. Finance, operations and IT will supply subject-matter knowledge throughout design and testing. Their contribution affects capacity elsewhere in the business.
Approval requires a total cost of ownership and a named owner for each expected benefit. The investment paper must explain how those benefits will be measured after go-live.
2. Has the organisation defined the scope?
The organisation needs an agreed record of the processes and business outcomes covered by the programme. For each part of the current GP environment, the record must state what will transfer and what requires redesign. Decisions on retention and archival belong in the same scope.
Every customisation needs a current business requirement. Where the standard platform meets that requirement, additional development adds cost and future maintenance work without a corresponding operational need.
Formal change control protects the approved scope. Each new requirement needs an owner. Approval must record its cost and the decision of the appropriate authority.
3. Are the data and integrations understood?
The assessment needs a complete inventory of systems connected to GP. Each entry must identify the business process it supports and the person responsible for it. The inventory must also record the effect of a failure. It must cover payroll links and banking interfaces, along with any sector-specific applications used in routine operations.
The data scope must distinguish operational records required in the new system from historical material retained for reference. It must also specify how the organisation will correct unreliable records and reconcile migrated balances.
An undocumented interface threatens any process that depends on it. Unreliable data compromises reporting from the first day of operation. Readiness work gives the project team an opportunity to resolve these issues before cutover.
4. Does the business have the capacity for the programme?
ERP migration changes approval routes and reporting responsibilities. It also alters the hand-offs between teams. Managers need to map the affected roles and explain how the future process will work.
Training limited to new screens leaves employees without the operational context for those changes. The programme needs role-based preparation and access to support during the first period of use.
The timetable must reflect the availability of the people required for design and testing. A schedule that excludes their existing responsibilities gives executives an unreliable view of delivery capacity.
5. How will the programme protect continuity?
The continuity plan must identify the functions that cannot tolerate interruption. Invoicing and payroll carry different timing constraints. Inventory and customer service require cutover arrangements suited to their operating requirements.
Each critical process needs tested cutover instructions and an agreed contingency plan. Acceptance criteria must be signed off before the organisation confirms the go-live date. A rollback decision also requires clear authority.
Organisations with several entities or operational sites may choose a phased rollout. The dependency map must confirm that interim arrangements will preserve the required flow of information.
6. Does the proposed platform and partner meet the requirement?
The product review must examine the vendor’s roadmap and the organisation’s access to its data. Contractual terms need scrutiny, including the practical effect of a future partner change. Release management also requires an owner inside the organisation.
Each customisation adds work to a future upgrade or change of partner. The design record must explain why the standard platform cannot meet the relevant requirement.
The partner’s proposed scope must demonstrate an understanding of the organisation’s processes and constraints. Its architecture and delivery assumptions must address the risks identified during assessment.
Conditions that require a pause
Pause executive approval if any of the following conditions remain unresolved:
- The business case excludes material internal costs or post-go-live support.
- The project team has not identified all critical processes, data sources and system dependencies.
- The design relies on extensive customisation without a recorded business requirement.
- Operational leaders cannot release the people required for design and testing.
- The continuity plan lacks acceptance criteria or clear authority for the go-live decision.
- Commercial pressure has set the timetable before the organisation has completed its readiness work.
A pause gives the organisation the opportunity to complete the missing work before it accepts implementation risk.
Evidence required before implementation
Before the board approves implementation, management needs a documented assessment of the current GP environment. The business case must include the expenditure required during planning and transition. The future design needs clear boundaries. Scope and data require named owners, as do integrations and operational continuity.
The roadmap must record each outstanding decision and the authority responsible for it. It also needs the evidence required for go-live approval. This gives executives a clear record of the basis on which the investment was approved.
Use the support period to prepare
Microsoft’s timetable gives Dynamics GP customers until the end of 2029 to prepare. The first task is a documented assessment of the current environment and the organisation’s capacity to undertake the work.
Download Braintree’s ERP Migration Roadmap for a structured record of the work that requires executive approval before implementation.
Braintree assesses Dynamics GP environments and develops migration roadmaps around each organisation’s operational requirements. Speak to one of our experts to discuss your current environment.
Sources: Microsoft Learn, “Understand the Lifecycle Policies for Dynamics GP”; Microsoft Dynamics 365 Blog, “Explore migration options for Microsoft Dynamics GP and Microsoft Dynamics SL customers”.
