Where we started
We from the <PROJECT_NAME> team (Digitalisierung mit A12 in Schleswig-Holstein) upgraded our “Webtool” application to the latest A12 version - in order to take advantage of the latest A12 features, in particular modelling features.
As our “Webtool” allows power users to create their own applications by modelling them and uploading those model into the Webtool, additional modelling capabilities directly benefit our customers.
We migrated to 2025.06 (base version) earlier this year. See AASH: Upgrade to A12 2025.06
What we did to upgrade
For this minor upgrade, there was no script support so we
- Upgraded the version numbers in our
build.gradle - rebuild our
package.jsonfrom the latestproject template. - migrated all models using the upgrade feature of SME
For the most part, that did the trick, except some hick-ups.
Backend adaptions
Spring boot complained about now having two instances of documentSerializer beans, so we had to implement an explicit constructor and use the @Qualifier annotation in every @Component that uses the DocumentV2Serializer.
Also the ListIProblemReporter appears to have fallen out of favour when using the serialiser.
Frontend adaptions
It took us a moment to fix the package.json / package-lock.json versions for the A12 DnD support.
FieldBasedFiltering.toOperators() now takes a ModelState instead of DocumentModel as parameter. This caused some ripple effects throughout our frontend classes.
Thanks to Stefan Wulf for helping us with the npm and frontend stuff, which reduced our efforts in this area by about one order of magnitude.
Model migration
Though the migration of about 100 models worked fine (using the SME), for ominous reasons one Overview model escaped the version update.
Duration of migration
Overall, the migration went rather smoothly (thanks to Stefan, again), and we were done in less than two days.
Official complaint 
Deprecation of DocumentService.load()
Please take back the depreciation of the DocumentService.load(DocRef) method. This method is useful, handy and does exactly what is needed. We use it all over the place. More than that, it does exactly what is mentioned in the deprecation message. So why tf do you want to get rid of it?
Or do you really want force each and every project to create their own utility class?
