Dominic Jainy is a seasoned IT professional with a deep specialization in the transformative power of enterprise technologies, specifically focusing on how artificial intelligence and blockchain intersect with core business systems. With extensive experience leading both technical implementations as a consultant and managing operational outcomes as a leader, Dominic brings a dual perspective to the complex world of ERP migration. He has a proven track record of guiding organizations through the intricate transition from legacy systems like Dynamics GP to modern platforms like Dynamics 365 Business Central, emphasizing that success is rooted in disciplined planning rather than just technical execution.
The following discussion explores the critical pillars of a structured ERP migration strategy, moving beyond simple timelines to focus on organizational readiness and accountability. Dominic highlights the importance of a deliberate assessment phase to uncover legacy workarounds and stresses the need for a stabilization period that treats “go-live” as a beginning rather than a finish line. Throughout the interview, he provides actionable insights on maintaining team alignment, validating real-world workflows, and ensuring that end users are empowered to be productive immediately following a system cutover.
A “smooth” migration is often misunderstood as a project where nothing goes wrong. What specific performance metrics indicate a successful transition, and what practical steps ensure that end users are fully productive within the first few weeks following the cutover?
A smooth migration isn’t a mythical “perfect” project; it’s defined by how quickly the organization returns to its baseline rhythm. The primary metric I look for is business disruption—specifically, ensuring it remains minimal during the cutover period so that core operations never grind to a halt. We measure success by seeing users become fully productive within weeks, rather than the months of struggling often seen in poorly planned projects. To ensure this, the roadmap must be clearly understood by every stakeholder, shifting the focus from a purely technical upgrade to a structured transformation effort. By setting realistic milestones rather than aspirational ones, we give the team the breathing room needed to master the new interface without the pressure of impossible deadlines.
ERP migrations can become chaotic when team members all “run toward the ball” without defined roles. How do you assign accountable owners to each phase, and what strategies prevent these phases from being compressed or blurred together as the deadline approaches?
Assigning accountability starts with recognizing that an ERP migration is like a soccer match; you can’t just hand people a ball and hope for the best—you need defined positions. Each of the four main phases, from initial planning to stabilization, must have a named owner who is responsible for the specific deliverables of that stage. To prevent these phases from blurring or compressing as the deadline looms, leadership must treat the readiness assessment as a formal, dedicated phase rather than a casual meeting. When we explicitly define the “Planning and ERP Readiness” stage as its own entity, it creates a buffer that stabilizes everything downstream. Maintaining this discipline prevents the project from becoming reactive, ensuring that no one is “guarding the goal” alone while everyone else is chasing the same task.
Readiness assessments are frequently treated as informal chats rather than structured evaluations. What specific “reporting blind spots” or undocumented legacy workarounds typically surface during this phase, and how do you reconcile these with the requirements of a new system?
The readiness assessment is where we move from assuming readiness to measuring it, and it often reveals a “temporary” Excel report from five years ago that has quietly become essential for executive decision-making. These undocumented legacy workarounds are common in Dynamics GP environments and represent significant blind spots because no one formally recorded how they were created or what data they pull. We reconcile these by evaluating process maturity and documentation early, ensuring that master data is structured and governed before a single line of configuration begins in Business Central. By surfacing these gaps during the assessment, we avoid the exponential costs and delays of trying to fix missing requirements during the testing phase or, even worse, after the system is live.
Configuration decisions made early on have a massive impact on future workflows and reporting. How do you validate integration touchpoints during the testing cycle, and what methods do you use to ensure that training exercises reflect actual real-world tasks?
Validating integration touchpoints requires a commitment to multiple testing cycles that specifically look at data accuracy and workflow flow between systems. We don’t just test if the software “works”; we validate the configuration against the documented reporting dependencies we identified during the readiness phase. To make training effective, we move away from generic tutorials and instead align every exercise with the specific, real-world tasks that users perform daily. This builds confidence because the staff isn’t just learning a new tool; they are learning how to do their actual jobs within a new environment. When the configuration is grounded in these validated real-world requirements, the transition from training to daily operations becomes a natural progression rather than a steep learning curve.
Many organizations mistakenly celebrate go-live as the end of the journey rather than the beginning of optimization. What does a disciplined stabilization phase look like in practice, and how can leadership maintain momentum once the initial technical build is complete?
A disciplined stabilization phase is characterized by a shift from “getting it to work” to “making it work better.” It’s a period where we focus on refinement, addressing the minor friction points that only emerge once the system is under the pressure of daily business volume. Leadership maintains momentum by communicating that go-live is merely a milestone, not the finish line, which helps keep the project team engaged for the critical optimization work that follows. This phase is actually where the real ROI is often realized, as we fine-tune workflows and data alignment based on live feedback. By planning for this period from the start, we prevent the “post-launch slump” and ensure the organization continues to move forward rather than just surviving the change.
Skipping discipline during the planning phase often leads to missed dependencies between departments. Can you share a scenario where a rushed timeline caused friction during the transition, and what specific steps can be taken to rebuild user confidence after a rocky start?
I have been in rooms where leadership treated the technical build as the only “hard” part, skipping the discipline of departmental alignment and resulting in missed dependencies that only surfaced at the worst possible moment. When a timeline is rushed, users often face incomplete reporting or poor data alignment, which immediately erodes their trust in the new system. To rebuild that confidence, you have to slow down and return to the fundamentals: listen to the users, acknowledge the gaps, and implement a structured “cleanup” plan that addresses their specific pain points. Rebuilding trust requires demonstrating that the system can eventually make their lives easier, which often involves re-training and correcting the data issues that were ignored during the initial rush.
What is your forecast for ERP migration?
My forecast is that ERP migrations will increasingly shift away from being viewed as “IT projects” and will instead be recognized as essential “business transformation” initiatives. As organizations move toward cloud-based environments like Dynamics 365, the focus will move from the technical difficulty of the “build” to the strategic importance of data governance and human adoption. We will see more companies adopting a “readiness-first” mindset, realizing that the cost of poor planning—expressed in lost productivity and eroded user confidence—is far higher than the investment required for a disciplined, phase-based approach. Ultimately, the successful organizations of the future will be those that treat their ERP not as a static piece of software, but as a living platform that requires ongoing optimization long after the initial go-live date.