Forget about “Divide to conquer,” think “consolidate to control!”

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 do.

Remember 2 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 on 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 a better control on 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, 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 routes 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 2-gateway route to a 1-gateway path) may affect your partners and business applications… But, when is it a good time to update existing running 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. Runtime data inputs can be collected using software monitoring features (even as simple as exporting your mailbox) or by using 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 configuration according to the new services you want to promote
• Leverage administration API to automate the provision of the new configuration, this accelerates the transition and minimizes the risk of manual errors when re-keying all information into the new system
• Mitigate the impacts on participants, 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 2 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 deployment of the new infrastructure (or review in your case)
• Definition of your migration strategy – from the legacy to the new solution
• Actual transition of 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 browse the meeting room. This project is a fantastic opportunity to demonstrate the synergies of the 2 teams. You and your colleagues are confident that this work can be the first of many success to come in the area of the managed file transfer. You’re off to a good start, great job!