I've also seen this issue. In 1.26, the tag name changed from projectName to project. I edited all our config.xml files manually and it does the trick. Bad news is, that saving the configuration in Jenkins throws an exception.

I'd really like to see an automatic migration path for this.

if you have a lot of projects to correct:

cd <JENKINS-HOME>/jobs
tar cfz config_bak.tgz */config.xml
sed 's/projectName>/project>/g' -i */config.xml

(if you use it in promotions also: )

tar cfz config_bak_promotions.tgz */promotions/*/config.xml
sed 's/projectName>/project>/g' -i */promotions/*/config.xml

in web interface:
manage jenkins/reload configurations from disk

I've upgraded from 1.25 to 1.27 and it seems to automatically perform the upgrade when a project is built. Unfortunately I modified a few jobs before they were built so encountered this bug

This seems caused by 6243f6bcd5, splitting projectName into project and parameters.
This can be fixed with readResolve(), as described in https://wiki.jenkins-ci.org/display/JENKINS/Hint+on+retaining+backward+compatibility

There seems a little complex problem:

• project names in Copy Artifact < 1.26 accept axis parameters and build parameters by splitting with a slash.
• project names in Copy Artifact >= 1.26 accept only axis parameters, no longer build parameters.
  • This is the same bahavior to Jenkins core.

So readResolve() cannot simply split a old project name into a project name and parameters. It must consider whether values after a slash are axis parameters or build parameters.

I posted a pull request.
For it is difficult to fix the configuration automatically, a warning message will be displayed.
https://github.com/jenkinsci/copyartifact-plugin/pull/21

But it is not reviewed for a month...
There also left some other reviews, and no maintainer seems available...

The upgrade is automatic if you simply build your project after updating the plugin. You must not configure the project before building it. I closed PR #21 since it does not really solve the problem; there are various ways the storage could be upgraded automatically without requiring a build.

> The upgrade is automatic if you simply build your project after updating the plugin.

I know that and that cannot resolve the problem at all.
The problem is that, modifying the configuration before building breaks the configuration, and there is a case that a project administrator and a Jenkins administrator are different.

> there are various ways the storage could be upgraded automatically without requiring a build.

Do you plan to work that?
Or please let me know the outline of those ways, and I work it.

I think the difficulty is the case a project is not contained in ItemGroup other than Jenkins, and cannot be enumerated with Jenkins#getItems.
I have no idea about the proper way to visit all projects.