I guess lots of teams have already taken the leap from legacy tool to slice machine, and I would be curious to get your feedback and advice on how to lead the charge here. In particular, how did you plan ahead for it, listed the various steps to go through and ensured there was no blind spot left behind.
Happy to take any feedback and thank you in advance for your help and advice
Hey @josselin.milon, iIn practice, teams that made the move found that it’s less about following a strict checklist and more about communication, consistency, and testing.
A good first step is for you and everyone else on your team is to get familiar with Slice Machine so you understand how the equivalent features work compared to the legacy builder. And from there, it’s really about planning the transition in a way that works for your team. There’s no single “right” way to do it, but moving to Slice Machine is the right move, it’s recommended, since the legacy builder won’t support newer features like the Tables field, Slice previews, and more.
We have an unofficial migration guide for moving over, but it’s a bit dated and may need some updates.
Hi @Pau ,
I see you have published an up-to-date migration guide here, thank you for that!
We would like to migrate slices one at a time, using a staging environment in Prismic, but still have some reserves:
What are the risks of running some documents with both legacy, and migrated slices?
Is this because the content model changes?
Is there a change in the API response?
Is there a risk of adding new slices to a Custom type, and updating legacy ones from the slice builder, on the same Custom type?
We’ve been told by the support team that having the two systems together was not ideal.
Same questions for migrating for the new Custom types.
We noticed that the new page types returned the slices in the `slices` field, instead of the `body`. Is this the only API change we have to handle?
Thank you for your help!
Thomas
Mixing legacy and Slice Machine content is technically possible, but it’s strongly discouraged and should be treated as a temporary transition state only.
The main risk isn’t a single breaking change, but accumulated inconsistencies over time.
The Legacy Builder is deprecated, so relying on it long-term isn’t safe. We strongly recommend migrating slices fully to Slice Machine as soon as possible, rather than maintaining both in parallel.
Similar risks for mixing legacy custom types and new page types. It increases the chance of edge cases, especially as your models and API usage evolve.
The move from body to slices is one visible change, but it’s not the only difference to account for.
Over the years, several structural changes have been introduced progressively:
New field types (for example, Tables)
Differences in how slices and fields are structured
Subtle changes in Rich Text / Structured Text handling
Because these changes were incremental, there isn’t a single exhaustive list of API differences. For that reason, we strongly recommend thorough testing before and during the migration, especially if you plan to migrate slices incrementally.
Our best recommendation is that you treat the mixed state as temporary, avoid adding new legacy slices, test API responses carefully before deploying change. And more importantly, plan toward a full migration to Slice Machine to reduce long-term risk
This approach minimizes surprises and helps avoid breaking content or workflows later on.
Hope this helps clarify things. 
Thank you for your answer.
The mixed state will happen temporarily in the production environment, as we migrate slices one by one towards Slice Machine over the next few months.
We’ve purchased an additional Prismic environment to make all necessary checks before applying the updates to the production env. Our goal is to migrate, and test slices one by one to this env, and release them progressively towards the production env.
However, it means that for some time, we will have both Shared, and Legacy slices on some documents. Once we start playing with Slice Machine, we will -of course- no longer create, nor update Custom Types from the Legacy Builder.
Does this sound reasonable to you, or should we make additional checks?
Thank you.
@thomas.digregorio Yes, I’d say that sounds totally reasonable.
The only extra thing I’d really stress is internal communication. Make sure your editors know which slices are legacy, which ones are being migrated or deprecated, and which ones they shouldn’t use anymore, so nothing gets reused by accident.
Other than that, you should be good 
@Pau Thank you!
Communication will be important, indeed.
Legacy Slices should be removed from the page builder by the migration tool from the Slice Machine, no?
I don’t see how Legacy Slices could be reused once migrated; could you detail this part?
Yes, that’s correct! What I meant is that for any other use case that might come up, manually recreating a slice isn’t the right approach because you’ll lose existing content.
If you create a new slice in Slice Machine with a similar structure and don’t plan to migrate the legacy version, it’s important to align with your team and make sure they stop using the legacy slice going forward.
That helps avoid confusion and content loss down the line.