I have started work on writing a tool to version the database schemas we use at work and enable migrations under version control. My first research into existing tools turned out to be too cursory due to searching for the wrong key words and I'm now aware of Flyway and Liquibase. Now I'm wondering if it wouldn't be better to scrap this pet project and just use one of these tools.
Some background: We work in a small team, namely one developer and several sysadmins and domain experts, who will use the software, but can't be expected to write any. Apart from different software project we use internally (a web platform here, some ETL processes there) we also have projects for each client that use the internal software projects in different capacities. Sorry if that sounds vague, but I can't talk in detail about it.
This is already one thing that may necessitate writing our own tool. As far as I can tell both tools mentioned above don't make a distinction between a schema and a project. We need to use the same schema for any number of projects. Still, there might be an easy way to customize these tools for this task.
Writing our own tool obviously has a lot of disadvantages and the only other uptake I can see is that development of the tool itself is much easier if you're familiar with it compared to having to understand a million lines of code.
I could also argue that the tool needs to be as simple as possible to be usable by the entire team, but then a wrapper around one of the "commercial" tools is likely still less work than getting the custom tool to a completely workable state.
What I'm asking is now what other aspects of "build vs buy" I have to take into consideration here. Does it all come down to the expected work hours poured into making a solution workable? Is it ever worth it to write your own solution?