Some of our earliest design decisions were:

- Everything one could do with point and click must be possible with an API call. A developer should build a clone using the API. Developers should be able to build products on top of this or use it as a subsystem in their systems.

- Build on top of common abstractions and units of 'thought'. Docker, S3, HTTP, JSON, etc.

- The platform must be able to die without users left scrambling to exfiltrate their work (based on my personal motto of being able to die without the team being impacted beyond nostalgia).

I can't say whether integrating your two products would give a pizza+ketchup, but if you are going that way, having APIs on both products could result in at least one prototype of a new product leveraging both without being entangled in anyone's implementation or limitation. Then slowly removing the scaffolding and replacing each API call with functionality from the new product and shutting down the functionality in the original product until none of the calls go to any of the two originals.

That is one way to do it with pros and cons. The pros are that you're not bastardizing anything or trying to fit a square peg into a round hole. One other advantage is that you get a first proof of concept that has the valuable functionality of both. Cons would be that the new code isn't battle tested and lacks the scar tissue. Like any rewrite, pros and cons.

Both of your teams are one team now. This is your new product. Both must be willing to kill/retire their own product or each team will try to make theirs survive.

> - The platform must be able to die without users left scrambling to exfiltrate their work (based on my personal motto of being able to die without the team being impacted beyond nostalgia).

I'm going to have to owe you a beer on this one. These are all very good points that I wish more services would take to heart.

>I'm going to have to owe you a beer on this one. These are all very good points that I wish more services would take to heart.

I know, right ! End of service notice email you didn't read that gave you a couple of days to think about and exfil years of work with no way to automate the thing ? Fuck that. Our users train models on data? Don't upload anything to us. We'll mount your S3 buckets like a filesystem.

Your company already has a billing account on GCP, AWS, Azure, or DigitalOcean ? We'll just link to your cluster. You don't need to budget for new compute or talk about security policies.

PS: I'm having a beer as I'm typing this. I'll drink it as if it were the one you offered. Thank you! It's delicious. Next few on me.

Here's a set of predictions worth what you are paying for them:

1. One of these products/services is going to die. The people who were making the dead product/service will know it pretty soon, and while a few of them will find niches in the new organization, many of them are going to hang around precisely as long as it takes financial incentives to mature.

2. Some of the customers who chose the loser will come over. All of them looked at the market and decided that there were good reasons for making that decision. If there's a third strong contender in the market, this is good news for them.

3. If you can craft a painless migration from the loser to the winner, many many many more customers will stay.

4. If you can identify the features in the loser that were attractive, and promise a realistic timeline to get those features in the winner, many more customers will stay.

5. In a few months to years, someone is going to push to re-do the whole enchilada with an architecture which is both trendy and can be sold as "best of both worlds". Unless they have an amazingly solid track record of leading projects on that scale, this will fail.

Personally, I'd stall a bit and see which of the two products starts to the win the politics war. In these kinds of mergers, it's typical for areas like sales or support to merge together before the software developers. That's when it usually becomes more clear which product is going to win out.

If it's clear, for example, that your product is going to win out, then working on "import from other product" is higher priority than "export to other product".

I am gonna join this opinion.

It's quite likely that one of the products takes over. Maybe one product had more traction with customers, or maybe one product is losing customers. Maybe the entire sales or development team will leave within a year, leaving one product in shambles. It's quite possible that one organization will be torn apart, who knows the terms of the acquisition.

Sometimes two products are there to stay - just ask BlueYonder, SAP, Korber or plenty of other large enterprise software vendors which end up with two products (be it merchandising systems, ERPs or WMS products they have ended up with via acquisition).

That's true, though more often the case with products that have a lot of overlap, versus really being competitors in the same market. Perhaps Trello is a good example. It overlaps with Jira, but it doesn't really compete for the exact same customers in an either/or decision.

It's hard to find a good example where a merger of two products with very similar markets where both products thrived after the merger.

I've been working on exactly that for the last 2 years. It has not gone well. I can't get into detail because it is all internal info, but I can give generic advice:

- Define your new solution first, worry about the tech later - the effort to make the tech work is worth it if you get the solution right. If your solutions came at problem from different angles, choose the angle you want to take based on what the customers need, not what the tech makes easy.

- Be willing to throw away old tech - re-use of legacy apps often brings legacy baggage. At the same time, don't re-write just because you can. Take each decision of re-use vs. re-write extremely seriously.

- Sadly, same advice for the people. My project struggled more with personnel concerns than tech concerns. Make sure everyone who works on the new product is not tied to the old work - not technically, emotionally or via their ego. Re-tool the team in terms of culture and skill up to whatever stack you want for the new product. Make that happen early - in the long run, getting the team right will make the difference.

- Merging two products is harder than writing either one in the first place, so be sure your leadership has accurate expectations of what this will really take.

First step: Do nothing. You've got two working, independent products, and that's okay. You can keep running like this indefinitely so there's no need to rush.

Second step: Figure out what the future combined product/company is going to look like. There's no sense doing any integration work until you know where you're going.

Third step: Form a combined team and come up with a plan to build the new product, reusing and rewriting the existing technology as appropriate. The details here entirely depend on the existing products and the end goal.

Keep in mind this situation can easily become political and toxic -- in fact, I would say that's the default outcome -- and will require strong leadership to navigate well.

The way I have seen this done in mergers I have been involved in is quite gradual. First, do some quick "day one" changes, where you change branding, and make the systems interoperable to some degree in terms of logins, file formats, terminology, import/export to each other, etc.

Then, gradually make changes to each system over time towards a common direction, and either they'll end up similar enough that you can pull the plug on one and nobody will notice, or they'll become two different offerings in the same family. Think of Windows 96/98/ME + NT 4, XP, etc - make them look and feel similar, different implementations that co-exist for a while.

Refrain from trying to make the long term decisions and planning on day one, and just see what happens with the market, personnel, etc.

If they're smart, they'll kill one of them. Unfortunately if you're on that dev team you've just become an outsider. Start brushing up your resume because you won't have any clout or credibility with the "winning" team. They will absolutely circle the wagons, I've been there twice in my career.

If I was in your position - I would push for integration of some sort while keeping the two products separate for now. Then have a separate team from both organizations start on a new product that borrows from both products. Obviously it’s easier said than done - ego have to be put to the side.

The advantage is you keep the status quo with minimal customer and cash flow distraction while working on integrated solution.

Right now, it seems your biggest struggle is with the number of competing ideas and priorities. You may need to invoke a series of developer honor duels and whittle it down to one chef in this kitchen if you want to survive.

Having 1 technical leader who can fight consistent and honest battles with the business makes things a lot easier in my experience. When it's 1 room of 10 people vs another room of 15 people, you aren't going to move anywhere. And if you do end up somewhere, it almost certainly won't be ideal.

My initial take was to say both codebases are now legacy, and both teams need to select a final tech stack for the rewrite. Without seeing the business and technology, that would be quite presumptive depending on priorities and market dynamics. That said, a clean start can sometimes be the fastest and easiest path if everyone is still fresh on the current codebases.

This sounds extremely familiar, so familiar in fact that if this post were written two years ago I'd be looking over my shoulder to see which of my colleagues was logged into HN.

Personally I can't offer too much advice, after a year or so of stalling I learned to polish my resume and move elsewhere.

There were endless top-down driven discussions, initially about how to merge to the favoured child, then about a "new platform" to encompass everything (but with an unrealistic scope and timetable).

It was clear that either this thing would never be built or would not achieve the level of integration desired. It was also clear it was only the board level who actually wanted this to happen, everyone on the workshop floor so to speak knew it wasn't what customers wanted or really a good fit.

So I got out.

Don't keep two similar solution working at the same time. Keep the one that has the better foundation, implement the most important feature of the second platform and migrate over all customers, kill the other one. If you don't do that, you will have to do it in a few years and you will have lost all those years.

Start with the vision of the company, which one is better suited to go to that vision ? Ignore all the details. I know it is hard, but that's a complex situation and it needs strong decision and leadership

There needs to be a transition project headed up by influential leaders, and they need to set out the synergy goals - things like what important services or features are key, which side will lead important aspects in the future etc…

Without a clear plan and good communications down to the lowest levels from above there are a number of ways chaos can ensue… not just technical differences but as you say org and people issues mainly.

Once the commercials are agreed someone needs to take the reigns on the transition aspects ASAP.

Thank you for your thoughts. I fully agree that it's critical to set up the relevant business targets for the integration, both short term and long term ones.

Do you really think a large and important project like this can be efficiently planned in detail ahead of time? And that the people who are not "on the floor" are the people with the insight to be able to pull that off?

It depends on the context I think - big or small company, personalities at the top, internal politics…

In the planning there definitely does need to be someone with the technical understanding on both sides giving input though. An architect or CIO or something.

Check change management. This is a complete field that goes way over just software integration.

The principal is that every human being is active and has a voice in the future architecture (based on spec).

Architecture is easy. Getting everyone on board is not. Luckily, it seems that human being are smarter together.

If you miss that, intern conflicts, architecture rejections will bring you integration project to a big failure.

Team / product competition is way easier to manage and is may be also the way to keep a bigger market share.

Kotter's new book "Change" does a good job of highlighting various scenarios and aligning them with principles of effective, rapid change. One of many written by him on the subject.

Thanks for the tip. I read now the basis. ie human psychology :)

Don't assume that they will ever be a single product - but do assume that they will move closer together.

Work out what that first task is - often the best place to start is the UX rather than the back end (as the UX may be easier to merge onto a single platform/codebase), and then you can have the two products having a similar 'look and feel'.

Then you can start looking at other bits to merge - for instance can you use the same database engine, languages, coding styles?

But the most important bit - don't go rewriting it all Big Bang otherwise you will just get yourself in a rut.

The part that will be the most difficult to change is the business logic - if the two products fundamentally have different processes it is very difficult to merge them together (from a customer perspective). A decision early on is required to know if they will fundamentally be two separate products, or if they will kill one and it will become one product, but you can't have one product with two different ways of doing the same thing for every feature.

I have experience doing this and am happy to talk offline as this is a complicated situation - just shoot me an email and I'll make time.

You will need to create organizational accountability for the integration and define what success looks like and how it will be measured. You will also want to avoid an "us vs them" situation inside the two companies.

There are a ton of subtleties in how to do that above that vary with organizational dynamics, but you must ensure that at a senior level you have alignment from both organizations or there will be a lot of shared misery.

Completely agree on the points here about organizational buy-in, apis, pros/cons of gradual convergence etc. I'd add UX into the mix. If these products have user-facing UIs they probably employ different metaphors, cater to different user persona's etc. Figuring out how (or if) to migrate users of A and users of B to C is part of the problem space.

Microsoft still fields about 4 or 5 different ERP products from various acquisitions under the Microsoft Dynamics label with no attempts to merge them. If the two products are so architecturally different, the most likely case is they will both coexist, or one of them will die with appropriate feature enhancements and a migration path to the other.

Been at a company that was acquired by a much larger company to more or less integrate it in, after a lot of push back, and politics, eventually the company was sold, and than sold again, and maybe again. Not sure if it was eventually migrated into the company that owns it now.

If you have the opportunity always tackle technical debt.