Hallo Leute! Today's post is about how I migrated from /api/v1/ to platform v2 🤓
This is the continuation of the <a target="_blank" href="https://blog.eichgi.com/reverse-engineering-a-platform">Reverse engineering a platform</a> post.
The next scenario for my brand-new compatible platform was to be in charge of the live app consuming the first backend (v1). Given I already understood how it worked, it was time to update the app in order to consume the new API. But unlike the new apps consuming the v2 platform this one was rooted to the initial database/storage process.
In order to be able to do a hot swap when updating, I had to:
<ul>
<li>migrate the database and make sure the new laravel's migrations fit as expected</li>
<li>migrate all the files to the new server (I could patch the links but eventually that server was going to be dropped)</li>
<li>add business logic for old and new files and data</li>
</ul>
It sounds easy but I spent some time figuring out several scenarios in order to pick the simplest solution. Once the roadmap was defined it was basically sew n' sing 😗.
After some polishing it was finally done. I saved some time so the users could make the update, and as usual, you know everything is fine because no one is complaining!
<img src="https://media1.tenor.com/images/d86a7d4f9caac0b10568b904b5b30bc5/tenor.gif?itemid=13361936" alt />
The cherry of the cake was the unlocking of some features I couldn't have it working in v1. This is how the software works essentially, iterate over and over until you have the desired outcome.
Stay tune for more 😎

Hallo Leute! Today's post is about how I migrated from /api/v1/ to platform v2 🤓

This is the continuation of the [Reverse engineering a platform](https://blog.eichgi.com/reverse-engineering-a-platform) post.

The next scenario for my brand-new compatible platform was to be in charge of the live app consuming the first backend (v1). Given I already understood how it worked, it was time to update the app in order to consume the new API. But unlike the new apps consuming the v2 platform this one was rooted to the initial database/storage process.

In order to be able to do a hot swap when updating, I had to:

- migrate the database and make sure the new laravel's migrations fit as expected
- migrate all the files to the new server (I could patch the links but eventually that server was going to be dropped)
- add business logic for old and new files and data

It sounds easy but I spent some time figuring out several scenarios in order to pick the simplest solution. Once the roadmap was defined it was basically sew n' sing 😗.

After some polishing it was finally done. I saved some time so the users could make the update, and as usual, you know everything is fine because no one is complaining!

![](https://media1.tenor.com/images/d86a7d4f9caac0b10568b904b5b30bc5/tenor.gif?itemid=13361936)

The cherry of the cake was the unlocking of some features I couldn't have it working in v1. This is how the software works essentially, iterate over and over until you have the desired outcome.

Stay tune for more 😎

How I successfully migrate to /api/v2 and more!

/api/v2 or something alike

I like to code and tinker with techs to improve my skills 🚀
