[Jefff8]

Firstly, it's important to note that on Hacker News, responders are probably going to be biased towards writing software that solves your problems.

Secondly, it sounds to me as if you are jumping ahead, and favoring one particular solution, rather than looking at this as business problem. If I were tackling it, I'd be making a list of all the possible solutions: - Stay as you are - Stay as you are but make a deal to buy the source code/or perhaps the company that makes the product if that's feasible/or the division - Buy-in an entirely different commercial platform - Build your own as a clone of what you already use, and extend out - Build your own as an entirely new system - something that exactly right for you - Glue systems together to get something that works for you - Probably there are more.

Then I'd list the advantages and disadvantages, the risks, and guesstimates on costs and monetary benefits. This does not need to be a long process - a month and a spreadsheet.

At the end of this process, I'd be thinking about next steps to facilitate the likely candidates. E.g. initial talks to vendors or approaches through an agent about buying the company.

If build-your-own is still on the list, then I'd look at having someone spend a few months documenting and thinking about your existing software, specifically with the aim of mapping out the likely pain-points - e.g. does the system use an interesting scheduling algorithm and if so, what is special, and where does it fail?

This stuff will eventually form the basis of spec for the backbone of a new system. But it's first job is to build some organizational expertise in the software, rather than the use of the software. You want some maps of the territory.

If at the end of this, you have a sense of the pitfalls, then I would think about mapping out what is really needed - interviewing all the levels of your org that have an interest - from the end-users/operators, through to the board. You want to find the stuff that's not documented. You probably don't want to get to a spec, but you do want to have a document that accurately reflects your needs (and also the love-to-haves, and the opportunities to extend)- and it can be used to judge whether a buy-in or a build-your-own can successfully meet your needs.

If you even get this far, this is the point at which you should be deciding between build-your-own and buy-in.

And if it's build-your-own, then this is where you take all the stuff you've learned to spec it.

And if this is the solution, I'd be thinking about what technology will serve you best at least cost, now and ongoing. E.g. should you be building a web app, and if so, what tech could function as the core, so that you don't have to spend money on re-inventing layouts.

Strategies - these are not secret: - Make your business a place that people want to work - that means getting rid of bullies and trouble-makers, and encouraging a supportive environment - Make sure there are challenges, and they are achievable - Offer excellent packages - this can be a mix - work-from-home, healthcare, pay, etc - it's the whole package that matters - Understand that if you don't offer people a pathway to improvement, then you will lose them - Ensure that the actual physical work environment is conducive to concentration - Ensure that the software team are a proper part of the fabric of your company, and not an afterthought.

Transitioning software too, is not rocket-science. You need a solid plan for the transition. You need to train people constantly. You need changes to be small, incremental wherever possible, and clearly communicated ahead of time; you want the people who use the software to feel in control - that this is to help them, rather than to hinder them. And if there are organizational changes as a result, then you need to be sure that you are not shafting staff; you want people on your side, not against you.