[FEATURE] Migration Document

[lechnerc77]

What area do you want to see improved?

documentation

Is your feature request related to a problem? Please describe.

When releasing the new provider we must guide user already using the Cloud Foundry Comunity provider on their way to switching over to the new provider.

The parameterization a s well as parameters names might deviate and also resources might be different, so we should make the transition as easy as possible.

Describe the solution you would like

I could think of a document (Markdown in this repository referenced from the documentation on the Terraform registry) that compares the setup of the same resource in a "before/after" kind of setup.

Example (not nice, but explains the idea:

Describe alternatives you have considered

n/a

Additional context

n/a

[github-actions]

Thanks for the feature request. We evaluate it and update the issue accordingly.

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[vipinvkmenon]

This makes sense and adds value. We will start working on this parallely.

[pyogesh2]

Planned for next week.

[SeanKilleen]

Love this!

If at all possible, I'd like for this repository to be approached with migration in mind:

• Reference points for which resources map to the community provider if they're not the same name
• A catalog by resource with their status, noting when they become stable.
• General guidance on dual-operating across providers with any relevant information, (so that users can ease the transition). I imagine some guidance about provider aliases etc. might make sense.
  • Happy to contribute to / bolster that as I've already had to use provider aliases to account for working in different CF environments.
• I suggest a migration guide from the community provider as a prerequisite of a resource becoming "stable". Nothing fancy, more a recommended approach to move from one to the other. I imagine the process will roughly be to import a resource into the new provider, remove the state of the old provider and the old provider code.