We've observed customers using crane to migrate from some non-OCP platforms
to OCP that are encountering apiVersion drift between the clusters such that
they have apis on their source cluster that are no longer present in their
target clusters. The specific and obvious example (which was hit) is:

Deployment extensions/v1beta1 -> latest OCP versions where this is not present.

We feel that kubectl convert plugin is a good way to help handle this.

Some insightful comments from rh-ee-dzager:

• crane is supposed to be the powertool for more advanced users, and these types
  of users will often be used to building their toolchain on the cli such that
  it's not unacceptable to advise them to actually go out an download / use
  "kubectl convert" plugin.
• The same is not true for RHO users, for whom this process of conversion should
  be transparent.

Questions to ask:

• Is kubectl convert something that will always work? Or are there scenarios
  that will actually require user input?

It's also notable that the correct answer for what the target apiVersion should
be is both a function of the GVK of the source resource, as well as a function
of the target cluster and the apiVersions that it actually has available. I.E.

(sourceResource, targetClusterAPIs) -> targetApiVersion

I suppose there is also a scenario where it will be impossible to actually
produce a recommended targetApiVersion, such as when no api is present that
matches on the GK of the sourceResource. In which case that's probably a hard
error that should fail the ClusterTask responsible?

This spike warrants an enhancement to explore these questions and to put forth
a solution for both crane and RHO.