[Koha] Upgrade planning tools and processes.

[Joonas Kylmälä]

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 at arts.ac.uk<mailto:lib-systems at 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 at 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