Is it a good idea to have a parallel sprint for two different releases?

It doesn't sound as though you have Sprints at all. You seem to have more of a gated waterfall process, within which people with certain skills end up being idle at certain stages.

Remember that the whole point of a Sprint is to produce a Done increment of immediately usable quality, so empiricism is established and maintained.

If platform validation testing and documentation were part of your product's Definition of Done, there would be no need for this special Sprint. Transparency is being lost every Sprint, and the later a problem is found the more expensive it will be to fix.

If your team isn't producing a valuable, useful, done increment every Sprint, your team is not using Scrum as intended. These types of impediments should keep a Scrum Master awake at night.

Add me to the list of "that's not how this works".  

Each Sprint creates a usable increment of value for the stakeholders.  If you are waiting to the very end to produce documentation or to validate that the "Platform" works, you are wasting a lot of time.  What happens if the Platform doesn't work?  Do the Developers and infrastructure team shelve the work they did, fix the previous "release" and then repeat the process over and over until the release is deemed "ready"? 

Is there a better way to manage sprints where we do not have to run two sprints at the same time?

Yes.  Each Sprint should produce something that can be pushed immediately to the stakeholders.  All documentation should be updated and ready.  "Platforms" should be validated. Then your next Sprint will repeat that process and over and over again.  Each time a Sprint ends you have something that could be released.  Whether you choose to do that is up to you. 

Also, pay close attention to the word increment. The Scrum Guide has this as the opening paragraph of the section that explains the increment.

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

There really shouldn't be any need for a final verification.  And if documentation is required for the work to be usable, it should be developed along the way with the code.

I don't think so its a good idea to have parallel sprints for two different releases, because this can lead to confusion, dependencies, and difficulty managing resources.