How can I demonstrate the impact of migration projects in a platform team?

Concrete metrics cannot measure everything for platform projects, but many other factors must be considered. There is some level of understanding from the leadership about the platform team projects. That is why your org has a dedicated platform team - to solve pain points so that the delivery teams can move faster and deliver business impact.

Some of the things you should try doing is

• Share weekly updates about this project's migration progress. In this, you can explain any technical difficulty you overcame and the benefit of it in the future. You can also highlight pain points referencing some issues/errors. The key is to produce regular updates until the migration is finished.
• If you have your weekly meeting with the team, share the progress and any technical direction you have followed, and ask about the feedback. These projects often run longer, so you must push the project's visibility and remind its importance for the business.
• Run a survey with the target internal team before and after completing the project. The survey could ask about the pain points before and the pain point addressed; you could collect many meta-points in this survey and feedback about the project.
• You should also rely on your relationship with team members who are the customers of your project. Have informal chats with them and ask about their biggest issues, things holding them back, frustrations with using the API architecture, and trickiest and most frequent bugs. This gives you a lot of reference points to collect and compare post-migration.

Some other related questions I asked earlier you may find helpful.

• https://www.jointaro.com/question/mvMQj8228kuUe38BvdT9/how-do-you-convey-impact-for-non-product-technical-efforts-like-adding-tests-and-fixing-crashes/
• https://www.jointaro.com/question/reItyrYxp8rMCyC03v2u/how-do-you-measure-the-impact-of-refactoring-your-codebase-to-use-a-new-pattern/

Here's another good discussion that's very relevant to this question: "What are the heuristics to plan the projects for the better engineering work stream?"

(1) How can I measure and demonstrate the business impact of this project, given that it is aimed at internal teams?

It depends on the motivation for the migration. It seems like the project is already in flight - This must mean that somebody at some point got buy-in from some segment of leadership: How did they build their case to do that?

In general, any allocation of engineering resources should have clear purpose behind it. If you don't have a clear grasp of this, I highly recommend digging around to find this out as you're the project lead. This is very crucial context to have, and it's an important behavior shift going from mid-level -> senior.

Given that you work at a Series B Startup, you probably don't need to add too much instrumentation. Even when I was at Meta, internal metrics around engineering efficiency were pretty nascent - It was hard for us to quantify the impact of big refactoring efforts.

A "hacky" way to get data around this is to run a survey across engineers who use the API architecture you're working on. This was actually the main way I showed my impact when I revamped the entire oncall system back when I was at Instagram: [Case Study] Revamping Oncall For 20 Instagram Engineers - Senior to Staff Project

(2) What metrics could I be using to quantify the technical impact of this project?

It could be some collection of the following:

1. Velocity to add/tweak APIs - If I were to guess, the main motivation behind your migration is to make it easier for other teams to do API work
2. Reliability of your API suite (volume of crashes, incorrect responses)
3. Performance of APIs (time to return a response)