We previously used a combination Axway Interchange and OpenText TLE. We had to switch because TLE was not being updated and people were moving away from the product. 

We did not want to go with OpenText's product because it did not offer on-premises, in-house maintenance. 

We chose the solution because it matched our requirements. 

The previous product was an in-house solution built on a Windows NT. We needed something with more security features and maturity.

I've worked with Dell Boomi. It is good for those who have less technical knowledge. IBM, Boomi, and MuleSoft have API advantages.

I have not used a similar solution to IBM B2B Integrator before.

We were using a simple FTP server that was sitting in the DMZ. We really needed a fully functioning platform and managed file transfer. This solution provided that.

We changed solutions because we looked at the stability of the product and the company's commitment to it.

We looked at what we were replacing in terms of our core integration product, which was already a product that IBM had acquired. It had to become an IBM product.

Certain parts of what we had in the environment were maybe usable by IBM. The reusability of its SAP infrastructure was a key decision.

Wwe were a Gentran shop before and all our maps were in Gentran so it was a natural progression to go to BDBI so we didn't have to redo our maps. We have maybe 600 different maps so we didn't want to reengineer all those in a new platform.

We have been acquired by another company, so we already have quite a few technologies that we use for the same thing. Even for EDI, we have TIBCO and Sterling B2B. For file transfer management, we use TIBCO Business Connect and Axway Secure Transport and Sterling Integrator. So, I think we are better placed to asses which is working better. So when we gauged them, we found the Sterling Integrator is really flexible and is able to support a lot of business use cases when compared with the other technologies.

When selecting a vendor, meeting our business needs, not only the current needs but also the future needs, would be the critical thing for us. If the current needs are met but you're unable to meet the future needs, then there is no point in selecting an application that is meeting the current needs but down the line we have to look for another alternative solution. It's such a big company and we don't know what kind of requirements are coming up. So, we have these periodic sessions to get an understanding of what is coming our way. Then we asses whether we could meet those needs or not. So, that's the reason why we proceeded with the procuring of Aspera, which is used for large file transfers in terms of like, terabytes or petabytes.
So that's a solution that we use that was acquired by IBM two or three years ago. So this is what happens when we get to know what's coming our way and we know IBM or the Sterling Integrator is not used for large file transfers, we may pull out another solution that would handle that.

We knew we needed to invest in this solution because our previous legacy platform was fully customized. We were out of date on the server, on the version of the product, and roughly 80% was custom scripted with Perl scripts that we had to support in-house. We needed a solution that we actually could go to support for, if there were any issues, and not rely on a couple of people who wrote a bunch of Perl scripts.

I wasn't using any other better solution than the one that I'm using right now. So, I think IBM B2B Sterling Integrator and Sterling File Gateway is the leader and I don't see any other product as compelling as that one.

I didn't use any other solution previously. Predominantly I was into IBM; I was working within IBM itself. When I left IBM, I joined a company that was also selling IBM software only. We have a DNSR contract. If a customer is asking for any specific region, then we can ping another vendor, however, we don't sell the other vendor's solution.

Yes, we had Trusted link translator V2 and V6 which are no match with respective to functionality we get from IBM sterling integrator so that was the reason we switched.

I started with a company that was using Connect Enterprise, and it was just too open to scripting.

People weren't writing the same type of scripts, and it wasn't the type of application where someone could come in and pick it up. It was good that they got Sterling Integrator.

I have some experience with a similar product called Axway File Gateway, but not too much. Axway is easier to set up. Apart from that, I'd say that they're more or less the same program. Nonetheless, I would still go for IBM because the aftersales service of Axway needs some improvement.

Previously, we were using Mercator, which is now acquired by IBM and now known as IBM WTX/IBM ITX.

We did a market research and then found out that this is going to be the less expensive solution, in terms of the cost, as compared to the other products.

When selecting a vendor, we just want the vendor to be flexible and who can go with a lot of iterations; and the cost; and then who has the technical capabilities; and then who is very strong in communicating things; and being fair in terms of the cost. We have a lot of issues in terms of dealing with the vendors, since their billing prices are very high.

We chose IBM because it's a great tool and is going to support us to do a lot of internal completion of the translation piece. Also, cost-wise, it's less compared to the other products.

I supported another product from TSI Software back in the 90s when Gentran
Basic was being developed.

The previous solutions had challenges. A lot of the customers came to us saying they wanted a new standard and what they had was failing. They said, "We need a better platform and we need something which has lots of enterprise trust."

We upgraded because of limited capabilities in an earlier solution which didn't keep up with the set of standards, such as the newer versions of EDI, X12 standards, that are available in the Sterling product.

We realized the necessity for separate components, like for communications software versus back-end translation software or evaluating solutions and hardware without buying multiple products to put together.

We were already an IBM shop but not to the newest technologies. So we ran into the situation where our systems were not as scalable. We didn't have end to end visibility, which became a key part of our business functions because we need to get into all the solutions.

We wanted to make sure that we have a single integrated application, which can fulfill the need of all the backend applications. Looking at the current solution to improve that was costlier. So we decided to go with an out-of-the-box solution from IBM, and that's where we are.

Previously, we were using Gentran. They chose to take it out from being an on-site/on-prem solution to the cloud. So, for those very reasons that I have mentioned earlier, i.e., as far as not having to worry about the configuration, setup and management, are the main reasons as to why we switched to this solution.

We were not previously using any other solutions. We are trying to move to the IBM EDI, which is the IBM Transformation Extender. It's an extra IBM ITX product that is what we are trying to use, because that's the bank's requirement/business requirement.

It was already in place when I got here. I know a lot of tools in this area have been around for a long time and they didn't really change that much. IBM has modernized it a fair bit so you make sure you're keeping up with changes in the industry.

We were using a different solution, many different ones, maybe we had three or four. The idea, really, was that in order to grow and continue our ability to partner with our customers and vendors, we needed a single solution. It was really a challenge.

I was not around when they chose the solution. At that point, I believe this was the best middle-of-the-road solution in the 2008-09 timeframe.

Our original architecture was WebSphere-based, so we were an IBM Business Partner. We started looking around and Sterling, of course, came out. So, it was a natural fate, more or less.

As I've mentioned, the reason why we chose Sterling B2B Integrator instead of others was that it has an end-to-end solution. It has mainframe parts, it has Unix and Windows parts and it is also a centrally managed system with Control Center. It is good and better than others.

There are some other solutions, but they don't cover everything. You have to use some other product for the mainframe side. You have to use some other management tools or something like that.

That's why we chose Sterling Integrator; it has good functionality. It is guaranteed file transfer delivery. FTP doesn't guarantee it. With FTP, you send a file, it says it can, but maybe it cannot.

We have been using this product for the last 10-13 years. They get better and better every time they have a new version. They fix issues that we had in the previous versions. We always want to keep up with the latest and the greatest.

We did not have a previous solution. This is a brand new solution we put together.

We were using mainframe. We were going to get rid of mainframe and that product wasn't going to survive out of mainframe. So, we had to look at something else.

I've used a number of different tools. We had Connect:Enterprise, which is a tool that is no longer supported; Gentran:Server on mainframe; and we had a Control Center on Linux and Sterling Integrator on another Linux. So we had a number of tools in different categories of our business and just knew that we needed to consolidate and bring everything under one piece of software so that we could manage it better with Connect:Direct, Connect:Enterprise, with encryption and decryption. So it was just a smart solution to put it all under one tool.

I have experience with a few similar solutions from different vendors. One of them is MuleSoft, which is leading in the support for microservices but are concentrating on API-related tasks.