I've been on both sides of this question so my views are both biased, and experience driven. In the early 90s we worked as contractors to a company developing

I've been on both sides of this question so my views are both biased, and experience driven. In the early 90s we worked as contractors to a company developing (DOS) software for them. They sold and supported it. They got acquired and after another year the new owners decided we were too expensive and took the development in-house (as was their right under the contract.) We moved on to some other things. Bearing in mind this was simply a continuation of the existing product, not a rewrite. They encountered the following problems; A) there were no existing senior people on staff with software development skills. So they hired a couple programmers but with no clear vision of architecture and no clear understanding of the implications of short-term decisions. B) it was already a "big" system, so it took time for new developers to get up to speed. Their developers would get a job offer somewhere else (paying more) so they had to get replacements. (Remember bringing the development in-house was supposed to be a cost-saving exercise, so they didn't overpay.) C) over the 6 years they stewarded this the product was essentially stagnant, with no major changes or additions made. 3 years after they took it in-house we spoke to them about a Windows product. We would build it (and pay for development) they would sell it (we'd get paid-per-sale). This took 3 years to build, and once that shipped the in-house work was abandoned. My lessons from this saga were; Developing in-house is expensive. And forever. Staff posts you add to do this will always be there. Development of big features will end, but maintaince is forever. Whatever you have budgeted for this, it'll cost 10 times that. And probably 2 to 3 times your (current gustimate) budget for years after that. If you plan to recoup thus investment selling to others (we did) add another 0 on the budget. Going from in-house to "product" is not cheap. You will need a senior systems architect who stays over the long run to make long-term decisions and to give the project "coherence". Some early decisions can be very important down the road. Hiring is hard. You want people good enough to do the job, but who are also looking for job stability. Be prepared to look again every few years (unless you get lucky.) My advice; figure out your budget. Have a sit-down, at very senior level with your supplier. Discuss your long-term relationship. Discuss how much you are willing to spend. Discuss how you might make the deal attractive to both parties. Make yourself important to them. By FAR this will be the cheapest approach, and the least distracting for you. If you can't come to a deal, figure out what it will take to transition the existing source code to you. Probably a big pile of money. It'll still be cheaper than writing from scratch. Ultimately recognise that software development is expensive, and the management of it is hard and distracting. (And in many ways counter-productive). Your best hope is to rekindle your relationship with the provider, which recognizes that you need, and want, to pay a lot more. If there are reasons they can't actually do what you need anymore then figure out the best way forward from that.