Topic Disclosure:

1. **What risks do we get when choosing opensource solution? Top rules to consider when deciding to use opensource:**

1. Few words first about pros of OS (free, community etc.)

2. Risks: Bugs can take a long time to resolve (may not be fixed at all) + examples. You might need to write Workaround’s or solve it yourself. Software can become depricated and lose any support (examples of response from support for such cases)

3. Top Rules:

1. Be careful which OS you choose. Keep in mind that if you make a fork of the repository (a certain tag or version), support comes to you. You can get away with it, but no one is save here

2. If the solution you choose has many dependencies, each of which evolves independently, do not be lazy to study the history of versioning and compatibility. It is quite possible that one of the elements of the system may dramatically change the way it works and bring you a lot of pain (As an example at some point one of your opensource dependencies can suddenly go from binary-extension to database extension, consisting lots of migrations. And so, rollback for such a case might become tricky). Besides, solutions are often offered for single-node clusters and multi-node (high-available) clusters (different configurations). In such cases the support and development are often not parallel either

3. Study experience of other companies. It is quite possible that the chosen solution may not be able to handle your needs.

4. Try the solution on sandboxes/playgrounds, often provided by the vendors themselves

2. **How and what we might encounter when using opensource when it has become depricated?**

1. Consider challenges and problems we can fase using opensource (ex. - Solution for your architecture & tech stack does not work correctly)

3. **Saving the drowning. How to survive? Our story**

1. In common, the right solution is to switch to another software that has support. Or apply the vendor's recommendations. However, the customer may not be ready to spend time and money on the migration and want everything to work here and now (at least for some time). In this case we need to fix what we have.

2. On our example I will tell what we faced, where we had problems, how we fixed it during migration from deprecated soft to non-deprecated

In brief: Opensource solution, that we were using became deprecated. From that time support of the system fell on our shoulders. While migrating to another solutions, we still needed to fix bugs and issues ourselves and keep system running. Main thesises:

1. Do not draw conclusions about the correct work of the system at once and not chase deadlines. It is better to observe time and load, than to shoot from your hip and fix the consequences.

2. Do not be afraid to dive into the source code and even rebuild your custom images (show our example)

3. Be sure to monitor the key critical metrics. Define them for yourself (also tell on our example)

3. Our story about moving from deprecated solution to supported one (TimescaleDB → Victoria Metrics). Main problems and thesises:

1. There is usually no ready-made solution (data-migrator), or it may not work well. You will probably have to write it yourself. What do you need to consider first for such a migration:

1. Define how your data is stored (which tables, whether key-value only, perhaps there are series and labels lists). How can you retrieve and migrate them as quickly as possible? Show it on our case

2. Understand how to bring data to the new system. How to parallelize and fasten the process (example: upload/download to each datanode (shard) separately)

2. As a conclusion tell how total time was spent on the migration process and how much control was needed.

4. **Costs and expenses. Price for moving from depricated opensource to a supported solution**

1. How much time does it take to implement whole migration process? From analysis to process start

2. What competencies are needed, specialists of which roles might be necessary to add to the whole process?