...
To that end this doc has a few items I suggest we think about for this kind of project. Each move is different and some of these are fairly specific to the type of move I attempted with modulestore - a new-to-edX coder attempting to move a large, old, foundational, platform component with unclear ownership or boundaries. I think we can assume that to be a worst-case scenario. 
Identify stakeholders
If you are not the sole consumers of the code, identify teams that also have a stake in the code early and make sure there is a representative involved in the planning and ideally in daily communication (attending standups, through daily project documentation updates, blog posts, etc.) as work progresses to keep everyone aligned as the project evolves and decisions are made.
...
What will look from the surface like a simple, clean move can quickly grow as you try to separate code that has grown organically into more formalized pieces. Leave time in your budget to refactor code to be more general in nature or to find solutions to break bad dependency chains. Make sure you understand how the code is being tested! Significant portions of the low-level platform test code rely on higher level code to load courses, etc. for testing and may need to be substantially refactored or rewritten to break dependency chains.
Take things in the smallest bites you can
...