Discover how you can get APIs and microservices to work at true enterprise scale.

Here it is, it’s just been announced on the market and the stocks are already going through the roof: your company is merging with GotBought Inc., one of your competitors, to become the number 1 in your industry. Congratulations!! After celebrating with a decent amount of champagne and petit four, you go back to your daily routine and let the excitement fade away. One morning, you are connecting to your favorite Managed File Transfer (MFT) administration UI and that’s when it hits you: you know for a fact that GotBought Inc. is not using the same solution as you.

Remember two years ago, when you tried to set up a bi-directional connection to share data between both your IT worlds (in hindsight, that should have tipped you off on what just happened, you missed your chance to make some money in the market). Their system was a little old: lack of some protocols like AS2, cumbersome to configure, and let’s not get started about data security! It’s clear that your technology choice was more tech-savvy and future-proof, and should be the one retained for all data transfers going forward. Great! But what’s next for the other system?

Why You Should Consolidate Your Managed File Transfer Systems, ASAP

During your first joint meeting with GetBought Inc.’s Managed File Transfer team, you bring it up: “we have to find a way to combine all our external connections on a single system, ASAP – then follow on with our internal data transfers.” Feeling that they may lose the battle, GetBought Inc.’s people are asking about the rationale behind such a rush, and you understand that. Luckily, you prepared for that question and clearly articulate your answer around the following points:

Get better control over your external business connections. Since both companies are playing on the same field, you obviously have some business partners in common. Using different routes to transfer data between similar parties can be quite disruptive in term of operations (as well as brand reputation) since you don’t have a centralized monitoring solution covering both technologies.

Improve operational efficiency with streamlined processes. You can leverage the lessons learned on both sides to review and enhance your operational processes and present a united front and customer experience to your users.

Decrease time-to-market by supporting a well-defined portfolio of services for your business and trading partners. By combining the technical features used by both business teams, you can build a robust set of capabilities that you can turn into a governed catalog of file transfer services.

Rationalize the variety of technical skills required to operate and maintain the solution. Your joint ecosystem now includes 4+ technologies related to data transfers. Cross-training both teams on all components is going to take time, and potentially affect the quality of service, for limited benefits – no one can be an expert on so many different systems.

Prepare for the new corporate direction that was announced as part of the merger: “become fully customer-centric within 24 months.” You know that this means looking at self-service capabilities for your business and trading partners, which requires a modern solution supporting API – and this is not something that GetBought Inc.’s products offer.

What to Consider When You Consolidate

Now that you’re all on the same page, you start discussing the best way to move forward. Different aspects quickly come to mind:

New architecture design. Lucky you, as you will reuse your existing infrastructure, it’s not really about designing (and deploying) a new solution from scratch. Instead, this step is more about reviewing your current capabilities in the light of your future Managed File Transfer Services portfolio. This is a key piece to make sure that you’ll be in a position to cover GotBought Inc.’s technical and business requirements.

Impact on your partners and business applications. You have to identify how much of GotBought Inc.’s configuration you can reuse since this will decide how hard you’ll have to touch your partner base: whether it is a simple notification that service may be impacted, or you need to completely re-onboard them. This is particularly true with the login credentials that are usually encrypted and can’t easily be exported from your legacy system.

Converting protocols and/or route topologies. Since you’re organizing your Managed File Transfer team around a new portfolio of services, it is a good idea that your platform, used for all transfers going forward, reflects this catalog. Converting protocols (ex: replacing all FTP connections with sFTP) or route topologies (ex: simplifying from a two-gateway route to a one-gateway path) may affect your partners and business applications. But, when is it a good time to update existing systems? Never! At least, if you combine it with your consolidation project, you will only impact your partners and business once.

How to Alleviate Your Pain During the Transition

Yes, that’s a lot to take into account. But the benefits are clear for both teams and totally worth the effort, so you all agree on moving forward. Your engineering background kicks in and you start to think about some tools that could help facilitate your work. In particular, you mention the need to:

Identify active configuration so you don’t migrate obsolete or unused configuration and that runtime data inputs can be collected using software monitoring features (even as simple as exporting your mailbox) or by using a product API.

Convert configuration from GetBought Inc’s systems into your current form. This step can be facilitated if you prepare templates for each of your new Managed File Transfer services, and concentrate on mapping GetBought Inc.’s patterns to your models. Note that if you’ve decided to convert protocols or topologies, you may want to extend this feature to also convert legacy configurations according to the new services you want to promote.

Leverage administration APIs to automate the provision of the new configuration. This accelerates the transition and minimizes the risk of manual errors when re-keying all the information into the new system.

Mitigate the impacts on participants, both internal and external. This can be done via wrappers (that mimics GetBought’s interface but update the logic to use your new system) and/or bridges (to easily route a file between the two co-existing solutions, until the participant is ready to adopt the new interface).

All those tools would support the main phases of your transition methodology:

Design and deploy the new infrastructure (or review it, in your case).

Define your migration strategy, i.e. how you'll get from the legacy software to the new solution.

Actually transitioning the existing connections to the new solution and patterns.

It sounds like you really thought the situation through – the why, what, and how is clear for everyone. Time to look at the “who,” which shouldn’t be the most difficult part when you look over the meeting room. This project is a fantastic opportunity to demonstrate the synergistic nature of the two teams. You and your colleagues are confident that this work can be the first of many success to come in the area of managed file transfer. You’re off to a good start, great job!