Единственные риски связаны с устаревшими (или, более вероятно, неявными) определениями пакетов.
Например, все ваши файлы Java, поскольку они находятся в одном пакете, не должны будут импортировать друг друга. После миграции им нужно будет либо использовать полное имя классов в других пакетах, либо импортировать их.
Аналогичным образом, везде, где появляется имя класса (например, в конфигурационных файлах Spring, возможно, в файлах свойств, которые называют классы), его почти наверняка потребуется обновить до полностью определенного имени (например, com.company.package.MyClass. "вместо просто" MyClass ").
Это последний, который, вероятно, будет самым неприятным; если у вас есть хороший процесс сборки и вы соберетесь с нуля, любые ошибки Java должны быть обнаружены на этапе компиляции (если вы не используете что-то странное, например Class.forName("MyClass") в исходном коде) , Проблемы с файлом конфигурации, тем не менее, проявятся во время выполнения, если не будут решены, а затем, как правило, когда они собираются использоваться. Если редко используемая функция имеет конфигурацию Spring, ссылающуюся на один из ваших классов, и вы забыли изменить его, вы не узнаете об этом, пока он не выйдет из строя.
С другой стороны, приличные IDE будут иметь рефакторинг "переименовывать" или "менять пакет", что также должно позволять находить имена вашего класса в текстовых файлах.