The 3 Essential Elements of Your MuleSoft 4 Migration Plan
There are a lot of good reasons why you may not have migrated to MuleSoft 4 yet. One of the most likely is the migration is a process and a project unto itself. It requires your organization to give it (the migration) attention – taking your time and effort from other projects and initiatives.
If you are looking for justification for the migration to MuleSoft 4, we think they fall into two categories; support and preparation.
- Mule version 3.8.x is in “Extended Support,” which means if you’re one of the many organizations that are still using this version, you’re only getting patch updates to the platform.
- Mule 3.9.x is the only non-Mule 4 version that is still in “Standard Support,” which goes away in March of 2021.
- If you’re looking for supporting content - like webinars, blogs, and training - you’ll find only Mule 4 content is still being produced.
- Mule 4 is much better for implementing use cases like SecDevOps, large file handling, and data synchronization, so your development productivity for these and other use cases should drastically improve.
- Mule 4 is the way forward, so all of your new MuleSoft application development should be done with that in mind.
It’s a good idea to get on with the migration. While we can sympathize with the challenges an organization faces with a version migration that’s as significant as the move to Mule 4 is, we’re also here to offer encouragement and guidance on how you can minimize the risk and impact of the migration.
How to Plan and Prepare for a Mule 4 Migration
The move from Mule 3.x to Mule 4.x isn’t trivial. It’s a “lift-and-re-platform.” A stable and successful migration from Mule 3.x to Mule 4.x requires three essential elements.
Comprehensive Application Planning
Your migration plan should start with a review of your Mule 3 applications. You’ll want to define:
- Which applications are mission-critical?
- The level of reuse for each application
- Groupings of applications by domain, such as customer apps, employee, and so forth
The output of this review is the input for your migration schedule. Having evaluated the existing applications, you’ll understand which will need to be migrated immediately and which can be migrated in phases.
MuleSoft has provided the Mule Migration Assistant, or MM, to help update your apps to prepare them for the new platform. Unfortunately, in the best of circumstances, the MMA may only automate 50% to 70% of your existing Mule 3.x code. Depending on how well best practices were applied to existing Mule 3.x code, you may find that some applications would benefit from a re-write instead.
And there may be some applications that are no longer in use, have functionality that is duplicated in another application, or no longer provides value. Now is the time to retire them.
Part of your application review will, out of necessity, include an assessment of your team’s readiness for the switch. While the general concepts of Mule 4 apps are the same, there are new concepts that your team will need to understand to effectively refactor existing code and be ready for support after you’ve completed the migration.
This plan will give you an idea of when you can schedule your production cut-over - another essential element of your migration plan.
NOTE: This may be an excellent time to revisit your technical debt rationalization process.
Architecture planning will be a critical element of your plan. It can help to ensure that you’re in compliance with your MuleSoft contract and that you’re maintaining and managing costs and infrastructure effectively.
For those using CloudHub, the migration is the time to review your vCore utilization and what you’ll need to support your applications after the switch. For those with hybrid or on-premise implementations, you’ll need to appropriately map your vCores while calculating things like your processors and compute services for your IaaS instances or your physical CPU mapping. We strongly recommend contacting your MuleSoft Account Executive when you are ready to migrate as they will be able to work with you to ensure compliance with your current MuleSoft contract.
Like physical, logical, and network security elements, network requirements will also need to be planned for as part of the cut-over. In addition to thinking through your integration architecture, you’ll also need to engage the right resources from other teams - like network, infrastructure, and security architects.
Together, your migration team can determine and plan how to handle the Enterprise Information System (EIS) requirements that will need to be considered. Will you need separate service accounts for testing? Will your Salesforce architect need to give you access to a sandbox to exercise those endpoints? What will the switch require in terms of connectivity, whitelisting, and IP management? You’ll need to think through these details with your colleagues in other groups for a smooth and successful cut-over.
Lastly, preparing the governance aspects of the migration will nail down the remaining loose ends.
Start with your methodology. Few companies can do a big-bang type migration; however, taking care of the move as a single sizeable waterfall-style event may be optimal for your organization’s situation. An agile methodology-based migration will require just as much attention as a waterfall methodology but can be spread out to occur in stages
Both testing of the new platform and continuing support must also be thought through and planned. Because the migration is a re-platforming effort, testing will need to include conceptually a set of regression tests that verify everything continues to work the same after the migration as it did before. The testing plans may also include some User Acceptance Testing (UAT).
Performance testing should be part of the plan, as well. Your apps should perform better on Mule 4, but if they don’t, you’ll want to know - and take the time to investigate why.
As noted above, support is part of your governance preparation as well. Your Mule 3.x implementation has been creating logs for years - what will happen to those logs now? How will you handle audits? What other SecDevOps requirements do you need to plan for?
Communication will be critical to a successful move to Mule 4. All affected teams should know well in advance what will happen and what the plan is. The production cut-over date and plan should be clear and available to all stakeholders. You should also plan to handle the initial triage after the switch - how will you prioritize issues? How will teams notify you of problems? Who makes up the triage team?
Once everything is migrated, you’ll also need a roadmap for handling the assets used for your Mule 3.x platform. Know when you’ll be retiring on-prem hardware or if it can be re-purposed. For hybrid implementations that leverage IaaS assets, you’ll want clear direction on when those assets can be released.
Lastly, schedule your lessons learned or retrospective meeting even before the production cut-over takes place. Give yourself time to breathe and handle and triage, but don’t push this vital task out too far. The retrospective meeting is an opportunity to find areas for improvement that could save you a lot of trouble down the road.
Ready or not, the time to start planning your Mule 4 migration is now. The urgency shouldn’t push you to put together a haphazard plan, though. Each of these elements - from application planning to architectural reviews and collaborative planning to your governance preparation is crucial to a successful platform update. Ignore these three elements, and you risk your migration taking longer, being more costly, riskier, and with higher technical debt than you hoped for.
If you’re not sure how to plan for a successful Mule 4 migration, or you just need a helping hand, Big Compass has the expertise and knowledge to execute a successful Mule 3 to Mule 4 migration.
ADOPTION & EXPANSION
+ Number of APIs
+ Business coverage
+ Number of contracted apps
+ API usage
+ API reuse
EFFICIENCY & COST SAVINGS
+ Number of APIs in each SDLC stage
+ Time spent in each SDLC stage
+ Cost and time to build an API
+ App development velocity
+ Number of launches per year
+ Number of defects
SECURITY & VULNERABILITIES
Time since the last version was published
Number of throttling issues
+ Time to onboard
+ Number of deployments
+ Number of incidents
+ Percentage of customers impacted. per incident
+ Time to resolve incidents