I assume that you are using static agents and thus are reusing workspaces. The git plugin is not sophisticated enough to apply the change of remote URL (or any other remote settings) to the existing workspace. If that is the case, then you can temporarily modify the pipeline script to precede the checkout scm step with a deleteDir step. That will erase the working repository in the workspace, it will then be cloned from the new URL and will write the new URL into the workspace.

Same problem exists when a job definition changes from using a shallow clone to not using a shallow clone, or from not using a reference repository to using a reference repository. The git client plugin and the git plugin record state data about the repository in the workspace but do not force the repository in the workspace to match the current values of the plugin state data.

markewaite I can't reach the `deleteDir` step even though it is the first step, because I can't get passed the required parameters. I tried copying the pipeline into a new job and it was unable to read any configuration at all. 

No Git repository configured in SCM configuration or plugin is configured wrong

tbretz94 that may indicate an issue in the git parameter plugin. Are you providing the repository URL as a parameter to the job? If so, then you might try redefining the job temporarily to not parameterize the repository URL, run it with the corrected URL, then add the repository URL parameter to the job again. There may be some internal storage of the repository URL in the git parameter plugin which is not being adjusted when you change the repository URL elsewhere.

markewaite The repository URL is only specified in the `scm` step and is not a paramter. Neither plugin has configurations available in the UI related to the remote URL. My only possible solution at this point is to change the IP of the new Bitbucket server, which amazes me that we can never change the IP because these plugins are not configurable on level beyond what is entered in the pipeline, and even then the configuration in the pipeline doesn't apply to the plugins.

deleting the workspace did not resolve this issue

For clarification, the new Bitbucket server was working for at least a week at the new IP address before this became an issue, and there are other jobs using the same configuration as this, but without the git parameters plugin. I don't think this has to do with the git plugin given that it is functioning correctly on the same jenkins instance in other jobs, although having the ability to configure the git plugin beyond what is given in the pipeline may alleviate the issue that causes other plugins to break.

The old address or hostname must be stored somewhere in the Jenkins system. If you have access to the JENKINS_HOME directory and can safely search it, you might search for it and use that location to make a guess about what needs to be changed to correct the problem.

It seems to me that the repository URL must be stored somewhere, otherwise Jenkins would not be able find the Jenkinsfile which contains the scm step. Where ever that is (job definition if a Pipeline job, multi-branch job definition if a multi-branch pipeline, organization folder if an Org Folder), assure it is the correct URL.