Modernization and Migration Services
Modernize and migrate your applications while also integrating and optimizing within your ecosystem. Transform how you develop new products, build up new skills, and manage costs while mitigating the risk of the platform. Ensure your systems are supported by an optimized, resilient, secure and scalable infrastructure.
Migration for Microsoft Dynamics
Dynamics 365 offers customers an entire business applications platform and ecosystem. If you’re thinking about migrating from Salesforce to Dynamics 365, it’s crucial to understand the differences in features, licensing, implementation costs, and AI tools.
Your Requirements Gathering are the foundation. At the end of your journey, those requirements should be met completely. You and your team worked hard to develop those requirements. You met in person, over the phone, and through written words over an extended period of time. You have a list of requirements with priorities in a sequence of importance that you all agree will enable your business to continue meeting your customers’ needs and those of other stakeholders as well.
Your team also kept additional desires and hopes you can attain that were not absolute requirements. These you might have labeled as “Nice to have” and they will certainly help your business or some subsets of the business but the needs were lesser in importance or you had workarounds available that would suffice.
Beyond simply documenting the requirements you have listed, you worked with your executives to ensure the requirements you have met their future needs as well. You and your migration team might not be aware of some plans for the future. Even more importantly, without the support and backing of those executives, your migration plans and hopes could quickly be swept away.
swept away.
You have a detailed plan to move from your current status to the end of your migration. That plan includes dates and milestones along the way so you can monitor your progression. There are many steps to be taken. Data migration is among the first steps.
The new ERP must be populated with data and much of that will come from your legacy systems. There are several categories of data and each will use different techniques. Fixed data includes basics such as your tax identification number and your address. These often are simply typed into the appropriate cells. Fixed data also includes your customers’ and suppliers’ names and addresses and related information. Start by identifying where these data will reside in your new Enterprise. These residences will be fields within tables. Next, find the same data elements in your legacy system and prepare a map detailing that table 1 and data A in the new system will come from table 14 field 23 in the legacy system. Determine if any data must be converted such as a date might be in one format and must be transformed to a different format. There will be data validation rules in the new ERP that must be followed or temporarily removed during your data migration. These rules might require that one table must be populated ahead of another or perhaps the dates in one table must be earlier than the dates in another.
Document the data migration process and track the time required for each step. Your data migration will be done several times during your upcoming testing and again just at your final go-live date. Testing might alert you that some part of your initial data plan must be changed in some unanticipated way.
If you haven’t started yet, now is the time to communicate. This is not a management project. This is not an IT project. It is an enterprise project and everyone is involved whether they are a user or not. Let everyone know why the business is migrating to a new system and what the expectations for the business are. Ideally, there are benefits to all users but even those who get no new benefits will gain when the enterprise as a whole benefits. There will be greater profits for all to share, won’t there?
When will the project begin and when do you expect it to be completed? What kind of hardships might users encounter during the project? Who will be doing the work and who will fill in for them while they are working on the migration? Will any benefits begin to accrue before completion? What work will people see as the project moves forward? Who are the strangers (consultants) setting up shop already? What can individuals do to help? Who can one talk to if they do not understand or disagree with this new direction? Will anyone lose their job because of this change?
Your communications at this time are only the beginning. Make a pact with your employees now to keep good communications throughout the migration
Let the migration begin! Hold a kickoff meeting where the migration teams get their assignments and get some enthusiasm for their efforts and some recognition from their peers for the work they are embarking on at this time.
Populate your new ERP with data from your legacy systems. Begin testing simple transactions in teams from each department. Simple transactions are ones like receiving a part into inventory or writing a check. Later you will test multi-stage transactions that might include recognizing the liability the check pays for and reconciling the bank account to show the check cleared.
Grade each test with a simple status. This could be green – the transaction worked as expected. Yellow – the transaction worked but there were some unexpected concerns. Red – the transaction completely failed. Now investigate all non-green transactions and understand what went wrong. If the team cannot find the reason, get help. There should be no red test results remaining at go-live and few, if any, yellow results. Is there an incorrect setup parameter to be changed? Are the instructions to make that transaction incorrect? Is there a problem with the migrated data? Understanding and correcting problems found in testing is absolutely critical.
Testing is an iterative process. Fixing one problem can lead to a new, unexpected problem. A test that passed as green yesterday can move to red today because a fix was entered to correct some other test.
Single transaction testing will lead to tests that combine several transactions in an overall process. Instead of receiving that part into inventory, you will create the purchase order, receive the part, run quality inspections, and then put it into stock. These combined tests will get the same green, yellow, or red results. Your final tests will be quite complex, perhaps taking a customer order, buying and making a product, shipping it to the customer, collecting their payment, paying suppliers and employees, and creating an income statement.
As testing proceeds, you will find the data migration from your legacy system will need to be updated many times. Sometimes only to create a fresh system for further tests and other times because you found some fault in the imported data. Repeated imports allows practice and improved import techniques. You want to know exactly how to manage the importation at go-live and how long it will take as that day, your business will be on hold for some time while the legacy systems have stopped but the new ERP is not quite ready for real business.
Migrating to a new ERP will cause stress in your employees, the implementation team, your customers, and your suppliers. Helping all of these stakeholders manage the change they see or anticipate is important.
Some of the change is overwork as people try to keep up with their jobs in the legacy system and prepare for their job in the new. Some stress comes only from change. There are people who have a difficult time making any kind of change, even one clearly for some better state. There might be others who do not agree that the change to a new ERP is beneficial to them or even to the enterprise.
Part of the migration efforts is to help all these people manage change as they understand it. Some of the help is psychological and you might want to employ experts to help. Ensuring that all get adequate training will help most people get beyond fear. Once they see the new ERP and understand their work can still be done satisfactorily many will accept the change.
Watch for hidden signs of stress. Not everyone’s stress is obvious and not everyone will ask for help. Use all your senses and try to help as much as possible to keep any stress from reaching a critical level.
Here is where the migration project begins to end. This could be the hardest workday of your life so get a good rest if you can. The testing is complete and results are good. All the users have passed their training. Anticipation is mounting.
Your team has set a specific time of a certain day when new transactions in the new ERP will begin. A few hours earlier, probably in the dead of night, your computer folks stopped your legacy systems from any new transactions and switched the data to a read-only mode. The final data migration started and it should be completed well ahead of the go-live moment. Your team has a few final checks when the data migration is complete to ensure all is well.
Someone entered the first transaction and it worked! Hooray! But now you find that many people suddenly forgot all that training and need their hand held as they start using the system. Soon, all seems well and the team heads for home and collapses into their beds after a really long day.
Wait a while, then look again at your ERP requirement list. Does the new ERP actually meet them all? Add up the value of the benefits and compare them to the actual costs of your migration. Is the ROI what was expected? Document the project for reference later as you want to retain your group’s learning.