If you have defined required custom fields for your issue that do not exist in your target project, you must set values for them. You will only be prompted to enter the values for required custom fields in the target project that are missing values.
So if you make the fields required in the destination project you are moving the issue to or if it is the same project you can set up a different field configuration scheme for the alternate issue type scheme as covered in "Associating field behavior with issue types" so that moving to the new issue type will prompt for the required fields in the alternate type.
The only caveat is that if have the field already populated in the source issue type location and you need the field to be changed to a different value then this approach will not work. In this case you would need to look into a workflow transition after the issue is changed to the alternate issue type to use a validator noting the current field value cannot be used, when the issue is transitioned requiring the value be changed before proceeding.
However, Jira does not have a option for this as a native validator so you would want to look at add-on apps that add in scripted validator options. One I am aware of that can do this in Jira cloud would be Jira Misc Workflow Extensions (JMWE) and I found the following in EXE in the vendors documentation on how these would work:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.