MuleSoft to Workato Migration - Why, What, and How

In recent years, businesses have continued to rely heavily on new technologies to stay relevant, competitive, grow, and be successful. There have been numerous studies that have been conducted in support of this trend as companies go through digital and cloud transformation journeys. It became quickly apparent that the various technologies, underlying systems, and applications, whether they reside in the Cloud or on-prem, will need to be connected in order for businesses to drive meaningful outcomes to consumers, internal or external in nature. This is defined by the broader term “Integration” in the world of IT. This is no new concept; however, it’s the manner in which you integrate that makes the difference. So, Gartner rightly coined the term iPaaS (Integration Platform as a Service) in order to explicitly underscore the importance of integration (the “Why”) in this digital and cloud-centric world that we have all started to live in. 

Since then, many software vendors have taken a swing at providing iPaaS capabilities to businesses with their respective take on the underlying architecture, which is essentially the “How” in this equation. 

MuleSoft introduced the API-led connectivity architecture approach which believed that every application, system, and process out there will need to expose APIs (Application Programmable Interfaces) in order to be fully integrated. And there are other vendors that believed in simply continuing to create P2P (point-to-point) programs that accomplished the same end goal. These approaches certainly solved the first step in the quest toward the transformation journeys - “connectivity”. And hence, there was a lot of adoption from across the various industry sectors toward iPaaS in general. But businesses continued to evolve, customer expectations continued to rise, the world started changing (think pandemic/post-pandemic) and different market forces came into play. We needed to be more efficient, more agile, more innovative, be faster, co-exist with bots, be automated, and drive bigger outcomes than ever before. A new world of automation and AI has started to emerge. This world requires less reliance on programming and coding skills, and more on building and generating skills. Workato introduced the “low-code no-code” platform that was aptly positioned to address this new world order. Their platform was built on the foundational principles of iPaaS, but with the power to drive automation and business outcomes at scale. Low-code now-code, as the name suggests, doesn’t require coding skills and hence doesn’t rely solely on centralized IT to produce technology solutions. Business units can quickly enable their citizens to be self-reliant in integrating and automating their systems of use, thereby, accelerating contributions to their respective businesses on a day-to-day basis. This is a HUGE differentiator. 

As we write this article, Workato has already established itself as a Gartner and Forrester leader in the category of iPaaS as it exists today. However, this category is expected to evolve in the years to come and have a significant emphasis on automation and AI. Workato is uniquely positioned to continue to remain a leader ahead of the other software vendors that have to play catch-up in an ever-changing landscape.

The focus of the remainder of this article is NOT to compare and contrast the various iPaaS platforms, or even between Mulesoft and Workato. But rather to help customers migrate from a MuleSoft API-led architecture to a Workato Recipe-led architecture if they so desire to be better equipped and prepared for this world of integration-led automation and AI.

Architecture and Migration Basics

It is important to spend a few minutes to understand the API-led architecture from MuleSoft vs the Recipe-led architecture from Workato. MuleSoft follows an API-led architecture where you would have APIs built across 3 layers - system, process and experience. System APIs are built as an access layer to the underlying systems through Rest APIs. Process APIs are built for services that perform orchestration and value-added functions. Experience APIs are built specifically for systems of engagement such as web apps, mobile apps, and external applications. All of these APIs along with their underlying flows will need to be converted over to Recipes and functions in the world of Workato. 

And my TL;DR for this section would be that there is NO migration tool that exists today that you can run in the background to magically convert all the MuleSoft based APIs to Workato based Recipes. 

Here is a table that gives you a quick overview of the various technical components and platform functionalities to be taken into account as you contemplate a migration from MuleSoft to Workato:

There are many reasons that goes into “Why” a customer had chosen to migrate from MuleSoft to Workato. The top reasons (and benefits) that migrating customers evaluate and realize from Workato are as follows (also supported by G2 survey of Workato in comparison to other platforms in the market):

• Ease-of-Use: Workato's visual interface and pre-built components significantly reduce the need for coding (aka low-code/no-code), making it easier for business users and developers to build and manage integrations, leading to increased adoption across the enterprise.
• Faster deployments: The cloud-native architecture and manifest-based deployments enable faster and more agile integration development and deployment cycles.
• Improved scalability and flexibility: Workato's cloud-based platform scales easily to accommodate growing integration needs and offers greater flexibility for handling diverse application landscapes.
• Better Performance: With the ability to auto-scale and auto-provision necessary resources behind the scenes, there is a significant improvement in the performance of tasks.
• Enhanced automation: AI-powered automation features streamline repetitive tasks and optimize integration workflows, leading to increased efficiency and reduced operational costs.
• Reduced Costs: The total cost of ownership (TCO) is lower and the value realized within a short period of time is higher, when compared to other platforms. 

Let's discuss the various migration approaches and the steps involved in our next section.

Migration Approaches

Typically, these are the 3 mechanisms to migrate from one platform to another:

• Option 1: Lift and Shift 
• Option 2: Rebuild/Replatform
• Option 3: Migrate using a Migration Tool

In order to accomplish lift-and-shift, the foundational programming language and the architectures should be the same. For example, if both the platforms utilized Java as the programming language, eclipse as the IDE, a transformation tooling such as XSLT that is generic and a deployment model (using Manifest/WARs), then we could have potentially considered this option of lifting and shifting. However, this is not the case as you can see from the table above. 

The only option that currently exists is option #2 which is Rebuild/Replatform. This may seem a daunting task at first for those who have been involved in the migrations of yester years. But in the world of “low-code/no-code” by Workato, this has become quite easy and less time-consuming. That’s why many MuleSoft customers have taken on this task in recent years and have successfully migrated to Workato within short timeframes (we are talking weeks and months for enterprises, not years as it used to be the case). And Twenty20 Systems have been fortunate enough to help a few customers in this effort with our deep expertise in both these platforms. 

Needless to say, option #3 doesn’t exist today and will probably be difficult to build considering the fundamental differences between the making of the two platforms. But, we remain optimistic that technology advancements can make this happen in the near future. 

Having the experience of being involved in many migrations over the years across integration platforms such as Oracle, Tibco, MuleSoft, Celigo, SnapLogic, Boomi and Workato, we have collected a rich set of best practices and an approach that will guarantee a smooth transition process for our customers. 

At the heart of this is a multi-phased approach (discovery, planning and execution) along with do/donts and resource commitments from all involved parties (customer, vendor and partner).

We would like to highlight a critical role that will be needed during the Planning and Execution phases as described above:

Workato Architect:

• To understand the architecture and the various Mule components of the existing implementation
• Identify the relevant components in Workato and design the new architecture for Workato implementation
• To identify the reliability layer added in Mule and avoid redundant components like AWS SQS as Workato, being an inherent cloud-native platform, has the reliability layer baked into the platform in the form of a Job report to monitor the performance and failure along with a mechanism to retry jobs.
• To assist/facilitate the Dev team and the Client Integration team with clarifications related to: 
  • Understanding existing Mule implementation
  • Workato implementation design
  • Implementation Technical challenges
  • Debugging/Troubleshooting technical issues
  • Deployment/Go-live doc creation
  • Post-prod issue resolution

Lessons learnt during the migration of a recent Enterprise customer from MuleSoft to Workato:

• • The requirements and design documents may not be accurate. Always read the latest Mule flows to understand the code.
  • The Workato OPA setup/config can be more challenging than you think - especially when you’re supposed to transfer a lot of data through it (or) when you have multiple OPAs set up with HA groups within a use case. This could potentially cause file locking/sharing conflicts that will be quite difficult to track and resolve
  • In certain large file conversion use cases (such as XLSX to CSV or JSON) with file sizes >100MB, you may want to consider alternative architectural strategies involving external routines or AWS Lambda functions.
  • Always check if you are using the right library for scripting actions. Make sure the library is optimised for memory usage and performance. Many a time, this is crucial for processing large files/payloads. If you find a certain library not working, look for an alternative library before considering it a blocker.
  • Target APIs for certain systems/applications may not be written to API standards. In such cases, you may have to build a custom connector to handle certain edge scenarios. One such example we encountered was related to the Hummingbird. Their API was responding with 400 bad requests for the Auth errors. We ended up creating a Custom connector using SDK to retrieve the access_token, by making a call to the list endpoint to refresh the token using 400 error code - refresh_on: [400, 401, /token has expired/],

Key Insight from Using Workato for Enterprise:

• Reducing the time to go-live is immensely beneficial for large enterprise teams. The conventional processes, involving security clearances and IT team infrastructure/resource provisioning often take weeks after UAT to make integrations live. Even minor configuration changes, infrastructure adjustments, or improvements can be cumbersome, requiring multiple rounds of approvals and therefore, significant delays. In contrast, with Workato, it's as simple as pushing the manifest file, adjusting the environment/project properties, connections, and Lookup Table (LUT) values and activating the recipes. This process hardly takes an hour or two at most.

Finally, we want to present a few KPIs that we helped achieve for an Enterprise customer in the FinTech industry using the above approach to migration from MuleSoft to Workato:

Customer Needs:

• Cloud Migration (from MuleSoft to Workato)
• iPaaS modernization
• 50% Reduction in Ops cost
• Citizen Development (low dev skills), Analyst Builders
• Faster Go-Live
• Enterprise-Grade security 
• Heavy on-prem connectivity from the Cloud

Key Outcomes Achieved:

• 51 Integration projects migrated in 6 months
• Built data pipelines for Snowflake
• 6 Departments/Business Units adopted Workato
• Enabled 36 Workato Builders (25 of them got certified)
• 37 Enterprise Applications were connected
• Added Autonomous error handling
• Reduced the AWS infrastructures, maintenance overhead and the associated cost with services like AWS SQS, S3, EC2, RDS, etc.

Isn’t that amazing? Of course, but the buck doesn’t stop with migration to Workato. There will need to be an ongoing effort to make sure that the platform continues to deliver the expected ROI over time. We recommend that an Automation Center of Excellence be formed within IT - this function will primarily focus on setting up and provisioning the platform/users, providing administrative support, enabling secure and governed access across the user community within the various business units, enabling the users with training and generate value reporting in the form of adoption/usage metrics. They would also make sure that no technical debt is created and push for re-use as much as possible. This will result in a federated self-service model that will deliver lasting business outcomes as opposed to a centralized ivory tower model that is entirely IT dependent. Now, this group is NOT something you will need to form ground-up with new set of resources, but rather re-align existing resources within the IT team. We also recommend that a regularly scheduled cadence (perhaps using quarterly business reviews) be established with Workato and Twenty20 post-migration to optimize and scale the value generated from the Workato platform over time and stay ahead of the innovative curve as the platform continues to evolve rapidly.

About Twenty20 Systems

Twenty20 Systems has been a Workato partner for the past many years delivering successful implementations to a variety of customers across industry segments. We have been awarded “Workato Delivery Partner of the Year - Americas” for 2023 by Workato and we continue to expand our delivery footprint across the globe.