1. Expecting employees to support a project like this and do their regular day jobs. They can't. One will suffer, probably the one that is new and unfamiliar. This will frustrate the team working on the project (whether it's in house, freelancer or contract firm).
You can hire some new people first and train them up in a short time to take simple tasks off longer term employees plates so they can spend some percentage of their time supporting the project. Don't hire new people to support the project, they don't understand your business well enough. This is a cost of doing this type of project that is often ignored. And don't allocate something small like 10% of employees time. It should be at least 50%.
2. Expecting the project team to get all the requirements. Understand, in detail, what you need to build. This is not the time for agile. You have a known system that you want to replace. You aren't discovering a new application space. You can run the project with sprints, agile rituals etc. But don't do requirements throughout the project. Get them up front so the team knows what they are building and can architect it appropriately. This is a topic that I could write pages about but you will wish you had better specified requirements no matter how well you do them. You can carve out a small piece of the application at first to limit the scope but that piece needs full reqs.
3. Get something done and in the hands of your users now. I like to start with a checklist of a process. Replace one item on that checklist. Repeat.
login to system
click shipping
fill in manifest -> identified as the piece to replace.
check schedule on calendar tab
login to system
click shipping
fill in manifest
login to new system
export manifest data
import into new system
check schedule on calendar tab