I definitely 100% agree with the previous answers, however, I am also interested to find out why weren't the bugs caught in pre prod environments. Obviously, the huge PRs make it difficult to review code, but even then, I don't think the responsibility of catching bugs is on the code review process. If the code deploy pipeline does not have enough integration tests or the repo itself does not have enough unit tests, this is a good opportunity to invest time in writing those. Apart from enforcing a process in PRs, there should also be focus on improving the code deployment process. Practices like integration tests in pre prod, canaries in prod, and proper instrumentation for catching anomalies earlier on will also help in this scenario. 

And, though it won't help your situation immediately, I would strongly recommend to carry out a repo split into multiple more manageable repos. Since you are a senior engineer, you should try to convince your team and management to invest in such an effort, as this will simplify ownership and also promote the velocity of roll outs in the future. 

Mid-Level Software Engineer [SDE 2] at Amazon

Siddharth Srivastava

There is some great advice in the above answers, a few things that I think can help are

1. Hold office hours, reserve lets say one hour slots twice a week and let the team members know that anyone can reserve time with you or just drop in. You can help them troubleshoot, review code/design etc during the time. Be strict with the slots so that you get time to work on your primary tasks.  
2. Avoid context switching as much as possible. I, for example generally work 90 or 60 mins blocks in which I pause notifications. 25 mins pomodoro sessions don't work for me because it takes me some time to focus and actually be productive. 2-3 blocks a day is a pretty good day for me.
3. Since you are relatively new at the company, its possible that you are not an expert on all stacks/areas in the team (often, a lot of history is needed to truly know the codebase well). If this is true for you as well, choose wisely on what you agree to help others with. 
4. Avoid doing repetitive tasks when helping others, If several people are facing an issue, can we eliminate the issue with a code fix or update the documentation etc. 
5. Delegate. If you just helped person A resolve an issue and person B also has the issue now, can person A help person B now.   

First of all, thanks for the detailed question. Its a scenario I can completely relate to and am facing something of this sort right now. I would attempt to answer your questions, but changing the order in the responses ( from the original order you provided)

**(3) How can I think about de-risking this attempt of the project and improving the probability of success?**

If the upgrade has failed a few times in the past, I would start by asking the past owners on the blockers they faced and documenting the same. Have the conditions changed from the past that we are attempting this project again? In either case however, trying to understand the nature of the blockers and what are the possible paths forward will help. Mentioning a couple of examples I can think of,

- a common scenario I have seen in upgrade projects is that the dependencies are not upgraded or won't work with another upgraded component i.e. we depend on x-1.0 and need to upgrade y-1.0 to y-2.0 but x-1.0 won't work with y-2.0. In such a case, we would need to contact the owners of x-1.0 to upgrade or pull it in the scope (perhaps fork it and do the changes ourself). If we are lucky, the dependency could be something minor and its easier to just write our own version of it than trying to upgrade the whole thing.
- sometimes the upgrade is not backwards compatible and the consumers of the service would break. There are two paths here, can we make the service backwards compatible? or can the consumers make changes to their side ? If there are external consumers then the latter might not be an option, unless the change on their side is to just upgrade to a new client.

The answers to the above questions ( and the ones you come up with respect to your project) can help estimating the risk and take a more informed guess at the success rate. The idea is "why did the previous attempts fail and what has changed?"

**(2) How can I come up with broad estimates and capacity requirements for the external and internal milestones if I'm not clear on what these milestones would require for completion?**

The only way to remove ambiguity from a complex task is to break the complex task/milestone into smaller tasks. Again, going back to the previous owners and looking up the documentation would help. For milestones that are so ambiguous that we are unable to break them into simpler tasks, a strategy I would use is to try ( or seek someon's help ) and correlate the previous owners' PRs to the milestones, and figure out how the previous owner sought to break the problem. A rule of thumb that my team has followed in the past is if the estimate of a task is more than 2 days, it probably needs to be broken down further ( of course, exceptions can be there). This exercise sucks but it generally sucks more without these finer estimates.

**(1) How can I identify smaller, independent high-level milestones that are relevant for external stakeholders?**

For this part, I would approach them ( perhaps cut a low/med sev ticket if too many stakeholders) and inquire from them about two things:

1. how much time do they need for testing in pre-prod before they have confidence of releasing the changes to prod
2. if output from your system changes in any way ( e.g. your service creates csv files in external stakeholder's storage and after the upgrade, the csv file sizes have doubled) will their systems break and how much time would they need to confirm it.

The answer to these questions would help in coming up with timelines and might pave way for more questions ( which lead to finer milestones )