Requirement gathering is often seen as a procedural step in ERP implementations, but in reality, it is the foundation upon which project success or failure is built. Having worked on diverse Dynamics 365 Finance & Operations (D365FO) projects—including complex implementations, I’ve learned that requirement gathering isn’t just about documentation. It’s about listening deeply, asking the right questions, and resisting the urge to jump to solutions too early.

Let me share what I’ve learned and what I wish more teams knew from the start.

1. Start with the Business, Not the System

Sometimes, stakeholders bring in a long list of features from previous systems or demos. This often leads to a solution-first mindset, instead of a problem-solving approach.

Instead, steer discussions around:

• Goals and KPIs
• Operational pain points
• Stakeholder priorities

This opens the door to more focused, value-driven requirements.

2. Avoid the “Laundry List” Trap

Stakeholders sometimes approach requirement gathering with a long list of features they saw in a previous system or during a product demo. The risk here is turning your requirements into a shopping list instead of a problem-solving journey.

Instead, guide them with structured sessions:

• What are your business goals?
• Where are your pain points today?
• What decisions do you wish you had better data for?

In one project, rather than just asking for “invoices to be sent via email,” we uncovered a deeper need: automated email invoicing per airline with customized backup details, driven by integration with flight and fueling data systems.

3. Segment Functional Areas Thoughtfully

In D365FO, the modules don’t operate in silos—and neither should your requirement sessions. Successful requirement gathering is usually broken down into focused sessions across functional domains such as:

• Finance (General Ledger, AP/AR, Fixed Assets, Budgeting)
• Supply Chain (Procurement, Inventory, Warehousing)
• Billing and Revenue Recognition
• Projects, Time & Expense
• Security, Compliance, and Reporting
• Integrations and Technology

Each area should be explored not in isolation, but in relation to upstream/downstream processes.

4. Always Align Requirements to Standard Capabilities First

Before proposing a customization or extension, always validate if the requirement can be addressed using standard D365 functionality. Many gaps that appear unique are actually addressable with existing configuration, workflows, or Power Platform integration.

✅ Tip: Start with a fit-gap mindset, not a gap-first mindset.

✅ Tip: Always ask: “Can this be handled through configuration, workflows, or Power Platform before we customize?”

5. Document With Scenarios, Not Just Statements

Requirements are often captured in bullet points like “System should allow multiple billing rates.” But without context, this can be misinterpreted.

✅ Better: “Users must be able to apply different billing rates based on contract type and service category. Rates should be effective-dated and defaulted where applicable.”

Use real-world process flows and edge cases to build clarity.

7. Prevent Workshop Fatigue with Structure

Extended workshops often lead to fatigue and disengagement. Maintain energy and focus by:

• Keeping sessions under 90 minutes
• Sharing clear agendas and outcomes
• Circulating pre-read materials
• Summarizing decisions and open points after each session

8. Collaborate in ADO (Azure DevOps) — or It Doesn’t Exist

As a colleague once said:

“If a requirement is not in ADO, then it does not exist.”

Capturing requirements directly in Azure DevOps ensures alignment between functional leads, developers, and testers. It creates traceability across use cases, tasks, and test cases. Verbal agreements or email threads are not enough—if it’s important, it should be recorded where the team works.

✅ Use ADO to track:

• Requirements and features
• Linked user stories and acceptance criteria
• Test cases and issue logs

Final Thoughts

Requirement gathering in D365FO projects is both an art and a discipline. It requires facilitation skills, product knowledge, business insight, and empathy. More than anything, it requires clarity—because unclear requirements lead to rework, scope creep, and missed expectations.

Whether you are a functional consultant, business analyst, or customer stakeholder, remember this:

💡 “Don’t just document what the system should do—understand why the business needs it to do that, and make sure it’s captured where it counts.”

Want to Collaborate?

If you’re planning a D365FO implementation or transformation and want structured, proven approaches to requirements gathering—let’s connect. I specialize in helping organizations translate complexity into clarity and execution.

📩 Reach out at info@pulse365.ca or follow me here on LinkedIn. https://www.linkedin.com/in/arshad-mohammed-603aa814/

Blog

6 Key Steps for Planning and Executing Data Migration in Dynamics 365 Finance & Operations Implementations

Arshad Mohammed 

Senior Consultant Microsoft D365 & Dynamics AX 2012 – Finance & Retail

November 24, 2024

Introduction: Data migration is one of the most crucial phases in a Dynamics 365 Finance & Operations (D365 F&O) implementation or an upgrade from a previous version. A well-planned migration strategy can ensure a seamless transition, minimize business disruptions, and enhance data integrity in the new system. In this article, Drawing on my hands-on experience and insights from the MB-700 Solution Architect course, I will present six key steps to plan and execute a seamless and successful data migration.

1. Conduct Data Migration Workshops Before Assessing the Data Landscape:

A well-structured Data Migration Strategy Workshop is a cornerstone of successful data migration in Dynamics 365 Finance & Operations (D365 F&O) implementations. This collaborative session, typically lasting 1–3 hours, sets the foundation for aligning all stakeholders on the migration scope, strategy, and expectations.

• • Stakeholder Involvement: Involve key stakeholders such as data owners, business process leads, IT/technical teams, and project managers. These workshops provide an opportunity to gather insights from different perspectives and ensure alignment on data needs and quality expectations.

• • Objective Setting: Define the goals of the data migration process and establish clear expectations with stakeholders. This includes discussing what data will be migrated, the scope, and any specific requirements or constraints.

• • Data Inventory Creation: Work collaboratively with the stakeholders to create a comprehensive data inventory, listing all entities (e.g., customers, vendors, Products, transactions (balances/historical) and their respective sources. This helps identify critical data elements and prioritize them for migration.

• • Roles and Responsibilities Assignment: During the workshops, clearly define roles for each stakeholder:

Data Owners are responsible for verifying the relevance and quality of data within their domain. Business Process Leads provide input on how data impacts day-to-day operations and ensure that critical business requirements are met. IT/Technical Teams plan the technical aspects of data extraction, transformation, and loading. Project Managers oversee the process, ensuring timelines are established and adhered to.

Workshop Output: By the end of the session, the team should have:

• • A clear understanding of the data migration strategy and its alignment with project goals.

• • Well-defined roles and responsibilities for the data migration process.

• • A roadmap for the next steps, including data assessment, cleansing, and migration execution.

https://learn.microsoft.com/en-us/training/modules/data-migration/3-workshop

2. Develop a Detailed Data Migration Plan

A clear migration plan is the backbone of a successful project:

• • Define Migration Scope: Outline which data entities will be migrated and the criteria for inclusion e.g., Master data, transactional (opening balances vs. historical data).

• • Utilize Multiple Environments for Iterative Validation:

Development Environment: Perform initial data mapping and testing for all entities. Use this environment for trial runs to identify and resolve mapping issues or errors in the data structure.

Data Migration Environment: Load cleaned and validated data into a dedicated migration environment to simulate the final process. Test entity relationships (e.g., GL accounts linked to financial dimensions) to ensure data dependencies are intact.

Functional Testing Environment (FT/UAT): Validate that the migrated data supports business processes during functional and user acceptance testing. Perform end-to-end testing to confirm that master and transactional data align with workflows, reports, and integrations.

Gold Environment: Serves as the staging area for the final data set, incorporating all master data and validated transactional data. The Gold environment will be continuously refined and updated to incorporate improvements identified during all phases, ensuring the most accurate and validated dataset is ready for the final copy to the production environment. Conduct a pre-go-live reconciliation to ensure data accuracy and readiness.

• • Set Realistic Timelines: Establish a timeline that accounts for data extraction, transformation, validation, and loading. Build in buffer time for unforeseen issues.

Develop a phased timeline that specifies the duration for testing and validation in each environment. Allocate sufficient time for fixing issues identified during migration and testing phases before proceeding to Gold or Production environments.

• • Assign Roles and Responsibilities: Designate a data migration lead and clearly define the roles of team members involved in the migration process, including data owners and technical resources.

3. Perform a Comprehensive Data Assessment

Assessing the current state of data is a crucial first step before initiating the migration process:

• • Identify Key Data Entities: Determine which data entities need to be migrated, such as customers, vendors, products, transactions (Historical vs Opening Balances), etc.

• • Evaluate Data Quality: Analyze the quality of the data to identify any issues, such as duplicates, missing values, or outdated information. Cleansing the data early will save time and prevent errors during migration.

• • Map Data Sources: Document all data sources (legacy systems, spreadsheets, databases) and understand their structures to create a detailed data map.

4. Choose the Right Tools and Methods

Selecting appropriate tools and methods is essential for a smooth and efficient migration process:

• • Leverage the D365 Data Management Framework (DMF): Utilize D365’s built-in Data Management Framework to handle data imports and exports. The DMF supports common data formats, allows for entity mapping, and provides validation features to ensure accuracy.

• • Excel Templates for Simplified Data Handling: Use Excel templates generated through the DMF for easy data preparation and manipulation. These templates allow users to format data correctly before importing it into D365, making the process user-friendly.

• • Manual Data Validation Using Excel: For organizations that rely heavily on Excel, create validation sheets to check data accuracy and completeness before importing. This step can help identify issues like missing fields or duplicates early in the process.

5. Validate Data Thoroughly

Data validation is a critical step to ensure the accuracy and completeness of the migrated data:

• • Perform Initial Load Testing: Conduct a trial run of data migration in a non-production environment to identify any issues with data mappings or transformations.

• • Involve Key Users in Validation: Engage end users and data owners in the validation process to verify data accuracy and ensure it meets business needs.

• • Check for Data Integrity: Validate that relationships between data entities are maintained (e.g., customer transactions linked to correct customer records), opening balances etc.

• • Conduct Multiple Trial Runs: Perform trial data migrations in the testing environments to simulate the complete process and validate load sequencing. Use trial runs to identify potential bottlenecks, such as long processing times or dependencies, and optimize workflows accordingly.

6. Monitor and Optimize During Cutover

The cutover phase is when the actual migration takes place, and careful monitoring is essential:

• • Establish a Cutover Plan: Create a detailed cutover plan that outlines the steps for data migration, validation, and system go-live activities. Include contingency plans for potential issues.

Prioritize data entities based on the order in which they are required for business continuity (e.g., customer and vendor master data before open transactions).

• • Monitor Performance: Track data load performance and resolve any bottlenecks promptly. Use monitoring tools to check for data integrity and system performance during the cutover.

• • Post-Migration Review: After the cutover, conduct a review to verify that all data was migrated successfully. Address any discrepancies promptly to ensure data consistency.

Conclusion: Data migration can make or break an ERP implementation. By conducting Migration workshop, thorough assessment, planning meticulously, choosing the right tools, validating data, and monitoring closely during cutover, you can ensure a smooth and successful migration process. With these steps, organizations can maximize the benefits of Dynamics 365 Finance & Operations and start their digital transformation journey on the right foot.

Have you faced challenges during data migration in D365 projects? Share your experiences or tips in the comments below! Let’s discuss best practices and learn from each other.