I have inherited a Meteor 0.7.2 project. The app is currently functioning in a production capacity.
I realize this is a very broad question, but does anyone have any advice on a path to upgrade (and/or what kind of issues I should anticipate)?
Also, this is my first experience with Meteor development.
Thanks in advance!
I don’t have an answer but I inherited a Meteor app as well. I ended up jumping from 1.8.0.2 to 2.2 .
The recommendation is to upgrade 1 version at a time and follow the changelogs and make the recommendations.
Ensure you can test everything as much as possible too.
From 0.7.2 to 2.5 you’re going to encounter a couple of major problematic areas - rather than going each version in turn, you may find it faster to jump between these versions.
You should of course look at all the breaking changes for intermediate steps too, but there’s little point resolving all the different package conflicts that arise with an upgrade when you’re just going to change them at each step anyway.
In general Meteor has done a fantastic job at maintaining core backwards compatibility. In almost all cases the problems arise with incompatible package versions.
When you come across a problem, search this forum for upgrades that closely match the current step you’re on.
Good luck - in particular around 1.7/8/9 - I had a 1.6 project that needed to get upgraded and this was the worst 
One secret superpower of Meteor (atmosphere) packages is that you can very easily modify them by adding a local copy to the /packages folder of your app.
https://guide.meteor.com/writing-atmosphere-packages.html#overriding-atmosphere-packages
When I’ve had to do big migrations, most of the issues have been from obsolete packages, a lot of which just needed very minor tweaks like version bumps to get the depenency resolution algorithm to pass
Also note that a lot of older atmosphere packages just wrapped an npm package, and for these, you are much better off ditching them and using npm instead
Another source of issues are npm packages with native addons, with big node version changes, they will need to be rebuilt and/or updated. This process is generally fairly easy, just time consuming as you go through them one at a time.
And lastly is migrating the mongo database between major versions. The mongo process is smart enough to automatically upgrade your database, but only does so one major version at a time. This is the main reason to update Meteor in separate version jumps.
If you don’t need to migrate any data, it might be worth deleting the whole db and updating directly to the latest version. A Mongo dump + import can also work here, but is less reliable.
The last option, which I have done once before, is to start by creating a new empty Meteor project, copying the app code in, adding required packages, and then dealing with issues.
This lets you skip the version dependency conflicts, and just deal with all the errors in one go.
The database caveats all apply here too, as it won’t be able to auto-update.
Good luck, you’re being thrown into the deep end 
The forums here are really a friendly and helpful bunch, so feel free to post issues as they arise
I second that. I was tossed into high pressure environment being only Dev and taking over Meteor app that was intended to be PoC by contractor. Company then wanted it to be used in Prod for live SCM stuff. Lots of hacky stuff going on in inherited codebase - but this forum is immensely helpful. Great community for sure
Create some integration tests or even better end to end tests with something like Selenium. Then as others mentioned update one version at a time reading release notes and what breaking changes there were. Run test suite after each update. If app not that big and you can write automated tests pretty quickly it shouldn’t be very hard. One thing where there are no criticism of Meteor is backwards compatibility - it is actually top notch. I think few days and you should be good.