For some context, currently my organization has a large number of graphql services that are all combined together into a single graph. And we did this before federation was a thing so naturally we are still using schema stitching to combine all of our graphs into a single graph to be consumed by our front ends.
We would like to move this system to a federated system so we have been experimenting and reading Apollo’s super handy schema stitching migration guide.
But after doing some research we came up with some questions.
We recommend that you begin by modifying existing services in place to support the federation specification while continuing to support schema stitching as well. At this point, you can stand up an Apollo gateway side-by-side with your existing stitching gateway and migrate over the links between the services in an incremental, backwards-compatible way.
First question, why is it recommended to stand up two gateways instead of just moving the existing schema stitched gateway to one compatible with Apollo federation?
Second question, since we already have our own schema registry and it would be a heavy lift to move all of our services away from this just to get started with federation is there any way that we can use our own registry on an Apollo gateway instead of Apollo studio?
I had stumbled upon the experimental_updateServiceDefinitions Option in the Apollo Gateway code and after play around with it for a little bit I was able to get our custom registry to work with Apollo gateway and federation. But the only thing that has me worried is that it doesn’t seem like this is a feature that is guaranteed to be included in future releases. 
Sorry for the long post but I am really liking what I am seeing with federation and I am eager to figure out the best path forward to get my organization federated 
1 Like
Hey Dan, great questions!
For your first, we recommend this approach simply for the sake of incremental adoption. If you treat the schema-stitched gateway as a single subgraph, you can start to break out pieces at a time. Performing a complete migration all at once is in most cases not an option for folks, and taking an incremental approach gives you an opportunity to learn as you go, become acquainted with composition errors, etc.
Secondly, while there is no guarantee we will continue to provide that API, we also don’t have any plans to remove it. Aside from what you’re looking to use it for, this has other use cases like implementing fall back behavior in case Apollo’s services are down.
1 Like
Thanks @trevor.scheer! Incremental adoption is super important to us. We want to be able to move to federation in the safest most efficient way.
The main reason that I am asking about having the dual gateway set up is that we discovered that by using our own schema registry and that experimental option we are able to use both federated and non federated services together in a single gateway instead of having to spin up a second gateway. This still allows us to slowly move our existing services over to federation while still supporting legacy services.
Using federated and non federated services in the same gateway seems to also accomplish the incremental adoption approach that we would be looking for by standing up two separate gateways. But with a little l less overhead because we don’t have to make any changes to our existing services that are using our schema stitched services.
So given we made this discovery is there any reason you could think of that we shouldn’t use this combined gateway approach? We are a little suspicious about that fact that this doesn’t seem to be a supported migration method and are curious why it wouldn’t be? 
I would be happy to cook up a code example of this scenario if what I am saying isn’t making sense
What you are saying seems to make sense, though I think I might be missing something. We recommend something like this:
(pardon the ugly formatting, discord isn’t friendly to whitespace, etc.)
…,…,…,…,.Gateway
…,…,…/…,…,…,…,…,\
Stitching GW…,…,…New Subgraphs
/…,…,…,…,.\
Existing Subgraphs
Can you explain or illustrate how your approach is different? It seems to be in line with our recommendation (which is why I think I’m missing something).
Just to make sure we’re on the same page here, I’m looking at our migration docs:
I see you mentioning “dual gateway” and want to make sure there isn’t any confusion - the docs mention a stitching gateway and an Apollo Gateway. This is old moving to new, not two Apollo Gateways running simultaneously. The two work together until the migration is complete, at which point you can remove the stitching gateway entirely.
I still suppose I’m missing something, so feel free to explain in as much detail as you need to help me understand. Diagrams might be helpful to illustrate the architecture, probably moreso than code samples. Thanks!
In this diagram you will see that instead of having a schema stitch service attached to an Apollo Gateway service, we just immediately switch our schema stitching service over to an Apollo gateway and just attach our existing services to the Apollo gateway.
I think what you said above makes sense. It sounds like in the recommended approach is really similar, but we would combine our schema stitched subgraph into the Apollo gateway service. Then any services we federated basically gets moved out of the schema stitched graph and attached directly to the Apollo gateway.
