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.
- Build a small core team who know the problem in depth. You really need to understand v1 and v2 data and the mappings, as well as the functionality in each.
- Build a test system that is insulated from customers; you want to be able to use this as if it's the real thing, but to be absolutely, completely, dead certain that it will not affect live systems, and that no output from this will reach people it should not. Make sure there are visual indicators as well as logical traps on data exiting this system. Make this repeatable - you are going to use this system a lot to re-run tests. Despite the firebreaks, you will have some brown pants moments.
- The ideal is to move from v1 to v2 gradually, using a passthrough system. However, ime, this is often not possible, and at some point there will be a hard switch between systems.
- Develop migration plans with multiple off-ramps and fallbacks, and monitoring. By the time you press the switch you should know exactly how everything will work, and you should have no issues, despite this, you should have layers of contingency to allow for business as usual when the unplanned happens. This is a mix between technical and business and it should have been properly understood by everyone involved. Monitoring is critically important. Your plans should include aftercare... for example, what happens if you think the migration is successful, and two weeks later you discover an issue with 200,000 transactions. How will you reconcile? How will you communicate with the affected parties?
- Look for classes of things... Can you find 100,000 dead accounts that can be removed? Can you find 500,000 that have only ever had one transaction? Look for classes of errors - and fix them before migration. Keep a record of all of this, and make certain that you have covered all cases and all records. If you are lucky, you will be able to migrate classes from v1 to v2 and have the passthrough transparently manage this.
- Ideally, have a log of transactions that can be replayed on demand. So that you can run systems in parallel and so that in the event of issues, you can unwind.
- Keep written logs of all the things that you and the team do. You _will_ forget stuff you've done. This is true on an hour to hour basis as well as a month-to-month basis.
- Work on making migrations fast. Can you organise it so that 16m migrations take 10 minutes? This allows you test and retest. You want anyone to be able to run on-demand migrations.
- Look to the end-users. For an upgrade to be successfully deployed, both the business and the end-users must be happy; you will want to run test groups, pilots, group conversations, and make your team available to the end-users. Nothing should be surprising by the end. You will also need to know that v2 is performant - catch these problems before they become general issues of dissatisfaction. Look also for pain points and try to ensure that you remove them in v2. Change is painful, but if you can show that there are benefits you will ameliorate much of the criticism.
- Have defined end-points. You do not want to be doing this in 5 years time.
No, that isn't exactly how insurance works, and it would be almost pointless for individuals if it did work that way.
Instead, it works by bucketing risk. In the simplest form, everyone is in one bucket, ignoring individual risk. That means that all other things being equal (e.g. size and value of your house), despite you have low risk of your house flooding, you would be paying exactly the same premium as the person who who has very high risk because their house is built on a flood plain.
Of course people paying more for their risk than it warrants may see that as unfair - so insurers use more buckets - e.g. bucketing high, medium and low risks.
But there's a delicate balance here - for instance, insurers may just decide not to insure the high-risk category. Or even if they do, the premiums may be unaffordable or the insurance benefits substantially restricted. And the natural extension of categorizing like this is to put an individual in a category by themselves - and then to limit payout. Essentially making the insurance not any better than a savings account, and probably worse if you don't claim at the beginning of the policy, before there's a large pot in the savings account.
From the point of view of perfect capitalists, the insurers would like to insure people with negligible risk, for high premiums, for low benefits - to make the most profit. From a social-good point of view, we would like insurers to cover risk that people cannot control (e.g. genetic risk) for reasonable premiums and good benefits. Categorizing lives somewhere between these two - a kind of necessary un/fairness.
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.