Hi, we had access to the Koha source code so we looked up there what changes were done to kohastructure.sql and in our case we were lucky that we could discard all the changes there. So basically what we did then was a set of SQL queries that reverted the DB schema back to kohastructure.sql from community's 17.05 koha version. So we first took the db dump from the modified 17.05 installation, imported it to the new Koha master version server, ran the SQL script to revert to 17.05 DB schema, ran updatedatabase and finally configured settings now to work with the new Koha version. The code is available here under GPLv3: <https://github.com/kohaputti/koha-migration-script/>. It is for migrating from https://github.com/KohaSuomi/Koha/ fork of Koha. Another thing we heavily relied upon to have similar features in KC master version was adding our own scripts to IntranetUserJS instead of implementing the features in Perl code. Also before the migration we submitted maybe a dozen or so patches to community that we had in the fork before and helped with reviewing some of the features we also needed. Also we are using couple plugins: https://github.com/NatLibFi/koha-plugin-rest-di and https://github.com/NatLibFi/koha-plugin-rest-biblios Joonas On 30/11/2020 15:48, Raymund Delahunty wrote:
We are looking to upgrade our relatively heavily customised version of 18.11 to 20.11 in maybe June 2021. Our server is hosted externally and we do not have command-line access to it. The Koha system is supported and will be upgraded by a software support company which specialises in supporting Koha and other open source products. I'd be interested to know what upgrade management tools and procedures support companies and other Koha users in a position similar to us have used in the past, and how successful the upgrade experience was, and if you think it was helped be less painful than it could have otherwise been, given the tools and procedures you used. We have used a google document managed by the support company in the past and at times I found it difficult to see a timeline and to know where we were, issue by issue, with the multiple issues being reported and needing advice / fixes. Rather than clutter up this List I'd be happy to receive suggestions and comments directly at lib-systems@arts.ac.uk<mailto:lib-systems@arts.ac.uk>. Thanks. Ray Delahunty, University of the Arts London.
This email and any attachments are intended solely for the addressee and may contain confidential information. If you are not the intended recipient of this email and/or its attachments you must not take any action based upon them and you must not copy or show them to anyone. Please send the email back to us and immediately and permanently delete it and its attachments. Where this email is unrelated to the business of University of the Arts London or of any of its group companies the opinions expressed in it are the opinions of the sender and do not necessarily constitute those of University of the Arts London (or the relevant group company). Where the sender's signature indicates that the email is sent on behalf of UAL Short Courses Limited the following also applies: UAL Short Courses Limited is a company registered in England and Wales under company number 02361261. Registered Office: University of the Arts London, 272 High Holborn, London WC1V 7EY _______________________________________________
Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
-- Joonas Kylmälä Tietojärjestelmäasiantuntija Kansalliskirjasto Kirjastoverkkopalvelut PL 15 (Unioninkatu 36) 00014 Helsingin yliopisto