[techguru007]

I am currently a fractional CTO and have held CTO, and Distinguished Engineer/Architect roles for Fortune 500, startups and several mid-size companies, with a single product AOR up to $2 billion ARR.

First and foremost -- document your business case and expectations of other Sr Execs as to sales-growth and OPEX comparison for the current state, and then the desired state.

Your current vendor will likely cry foul if you disconnect from them too quickly and without sufficient empathy. Consider the possibility of the current vendor stepping up to fill the gaps if you could negotiate terms with them that give you better ROI than having your own in-house team. And, would you trust them with the extra outlay?

Requirements, Requirements, Requirements -- cannot be stressed enough. Getting those right (even if they are a moving target) saves 10x development over jumping straight in with designers, and 100x savings over just hiring coders with no domain expertise. Most of your existing domain expertise is in your non-technical staff. They need to participate in a reverse-engineering of what your current system is actually doing for you, and help identify gaps in the current tech that would help their productivity or reduce other toil.

As the first hire, I would hire (contract) a top-notch software architect to lead a "requirements documentation" phase of 2-3 months before hiring anyone else to the team.

Does your current team have access to an underlying database schema? Can you quickly and clearly state how many "screens" your team uses in their current workflows? Can you quickly and clearly state how many unique fields there are on those screen? Same questions for EDI/ETL as for workflow screens. The answers to those questions can quickly reveal the size and scope of your existing system.