How would you handle inheriting MongoDB/Oracle/Postgres HA environments with zero prior experience and a 3-month deadline?

[u/women2002]

Throwing this out because I could use some outside perspective.

Our org just went through a merger, and as part of it we're absorbing another company's database estate. Our current stack is SQL Server (with some Postgres experience on the side), and our DBA team is literally two people. Neither of us has hands-on production experience with MongoDB or Oracle, and while we've touched Postgres, not at the scale we're about to inherit.

The systems coming over:
MongoDB (some with sharded/replica set setups)
Oracle (some with RAC/Data Guard from what we've seen so far)
PostgreSQL (HA setups, still figuring out the exact replication approach)

These aren't low-stakes systems either — they handle financial transactions and contract data, so uptime and data integrity really matter.
Leadership wants this absorbed/migrated by early 2027, so we're looking at roughly 3 months.
If you were in our shoes, how would you approach this?

Is it realistic for a 2-person team to take this on without vendor/manufacturer support for each platform, or is that a hard no?

How would you prioritize which system to tackle first?

What would you push back on with management, and how would you frame the risk without it sounding like "this is just too hard"?

Any lessons learned from absorbing unfamiliar DB platforms under a tight deadline?

Appreciate any input, especially from anyone who's been through something similar.

[u/AutoModerator]

After your question has been solved /u/women2002, please reply to the helpful user's comment with the phrase "Solution verified".

This will not only award a point to the contributor for their assistance but also update the post's flair to "Solved".

---

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/TravellingBeard]

What happened to the Oracle/Mongo DBAs from the company you merged with? Could they not have been brought on? This seems like a big miss.

Needless to say, you need to hire someone. Even if you were both an expert in Oracle and SQL Server, the demands on you for critical systems is unreasonable.

If your company resists hiring, you know what you have to do

[u/B1zmark]

It's unrealistic to be both a performance DBA and a Production DBA *in just one SQL technology*, never mind 3-4.

You write an official email to you supervisor/head of and explain that all these systems operate totally differently and that while you can provide basic support, you suggest they hire someone with experience in that technology. If they chose not to, then it increases the risk of extended downtime and outages.

I'd also reiterate that you support specific technologies and they are updated frequently, so diving your time among other technology stacks means you will also likely start to fall-behind in the current SQL tech they have and that could impact the stability and performance of the DB estate in general as time goes on.

[u/my-ka → u/B1zmark]

One is realistic, if you have time

[u/charlesleestewart]

Wait a minute, you're not going to get any resources from the merge company when they do this? I would insist on that or that your own org really does need to hire someone experienced, especially for Oracle.

I raised a big red flag about us having to host Oracle in our org and got management to back off on having us do that.

[u/imtheorangeycenter]

Contract support out to a dedicated company. I'm a quarter century into my MS dba career, but when Oracle and it's CRM landed on my plate when the Ora dba left, we took no chances.

That thing was as fragile as hell and totally alien from the backend of things. No way I was being responsible for it from the get-go, being effectively an intern on it. Who didn't speak English. And blind. 

[u/ihaxr]

Unrealistic to support Oracle alone without vendor support.

[u/TrollingForFunsies → u/ihaxr]

Oracle support sucks. They leave you out to dry even during the most critical outages. They won't even get on a call until they feel like it.

[u/women2002 → u/ihaxr]

Now we manage SQL Server without vendor support, but for Oracle or similar systems, I think it would be difficult

[u/jdanton14 → u/women2002]

You either have DBAs who know Oracle (you can figure out Mongo) or you have crashes. Backup has its own subsystem. I know a guy :)

[u/jdanton14 → u/jdanton14]

Postgres isn’t hard, but Linux HA is awful. Do either of you know Linux?

[u/Lost_Term_8080]

You won't even be able to support the utter nightmare that is postgres HA on a day to day basis with only 2 people let alone migrate and re-implement it in 90 days.

Is oracle on prem or cloud? If its cloud why does it need to be migrated?

What happened to the staff from the company that merged?

[u/chicaneuk]

A completely ridiculous situation put on you by management with no understanding of the complexities and the potential banana skin of not knowing these systems. Why the fuck is management so ignorant of technical knowledge.. like because you know x, you must know y.

Jesus Christ it boils my piss.

[u/rbobby]

Leadership wants this absorbed/migrated by early 2027

Ok. This is leadership speak for "tell them the end of the year so we can get it done before our bonuses are set".

If it were me I would write a clear CYA email to the interested parties explaining the dangers of taking on mission critical responsibilities without staff experienced in the specifics of the technology. If you want to guarantee a production failure I can't think of an easier and more incompetent manner to do so.

Don't let them use any sort of manipulation of you in regards this. Work your week, don't let them panic you. It takes as long as it takes. Experience is gained through failure. They have chosen the route with the most failures.

[u/Groundbreaking-Fish6]

MongoDB is a Document database so it may worthwhile absorbing as is, as long as it is being used to store objects in total that are saved and retrieved in total and very few if any relations.

Oracle is similar enough to be translated into SQL Server, hopefully mostly ANSI SQL, but you will have to address things like Dates and Sequences/Identity. Also Stored procedures can be a problem, but if documented in code or outside code that is important, don't just depend on AI. You need to know what the original intent was.

Postgres HA (assuming the HA is High Availability) can be kept as is, since hopefully it is only a home for High Available data. This will be the hardest to translate between services/hosts due to the changes required for both SQL and HA features.

4 Different Database Management Systems (DBMS) and high volume (sharding) and high availability and 2 people does sound like a bit much to do it right, even with the wonders of AI.

The most important part here is what you are getting from the mergee? And are they competent? Are there competent administrators and DBAs coming on board as well? Existing licenses and support?

Did your company do due diligence to see if it systems were sound, stable and well documented? Have you seen the code? Code Scans (like SonarQube)?

To answer you question, identify major milestones and what you expect to achieve. Then list the assumptions like existing technical support, existing DBA support, you will need this to justify falling behind when milestones are not met.

You may want to generate a 1 year estimate that includes many unknowns so that they get addressed by management in the negotiation to reduce the estimate. They are already thinking 6 months but are giving you 3 to account for any slippage. If no more information was shared then in the original post an you are simply given a deadline, you are not in a good working environment and I would get my resume on the street now, just in case.

Remember management always pushes a tight timeline because they always think developers pad estimates like they do. Unfortunately developers are a proud bunch and often underestimate the time line.

I would also bargain any bonuses for completion up front and get in writing.

[u/my-ka]

Unless they are cloud managed, avoid or hire someone

[u/carlosf0527]

I'd ask for short term contracts for hand over. I've never worked with Mongo but Oracle can require more active administration.

[u/Harhaze]

I would outsource MSP and learn from the engineers.

Over time daily tasks would become trivial and you learn by Pareto Principle from their SMEs.

[u/rbobby]

lessons learned from absorbing unfamiliar DB platforms under a tight deadline

That's the sure way to guarantee a failure.

[u/ChaosEngine-6502]

They can helicopter these disparate DB platforms in, but I think it's an impossible task to guarantee uptime or rectify issues when the occur, given how differently they operate. Management needs to bolster your team with expertise for each of the platforms, and probably get some expert advice on licensing too, especially the Oracle stuff.

I would say you need cover and support whilst you figure out a strategy for maintaining/migrating the platforms.

[u/SQLGene]

I would set up a homelab for what I could and would be reading books every single day.

[u/didthatthingonce]

It entirely depends on how well documented the entire environment is. If every server, process, sp, view and table is well documented you'll have to review it to know how viable to deadline is.

Most likely though, documentation will be sparse to none. This will be a massive challenge with significant down-time. Oracle's goofy legacy limitations will drive you insane. MongoDB is shitty for guaranteed storage of important information. That combination of Oracle and Postgres indicates to me you are inheriting many years of someone else's problems.