Skip to main content
Home

Main navigation

  • About
    • Program at a glance
    • Venue and rooms
    • Lunch
    • Contribution
    • Accomodation
    • FAQs
    • In the Media
    • Team
  • Schedule
    • Sessions Overview
    • Mautic Days
    • Venue map
  • Speakers
  • Sponsors
  • Tracks
User account menu
  • Log in
Event Platform Header CTA Pictures

Breadcrumb

  1. Home
  2. Should migrate be our goto for migrations?

Should migrate be our goto for migrations?

Room
HS4 (Ground level)
Time Slot
Thu 2:00pm to 2:45pm (7/20/23)
Session length
Long session - 45min, including Q&A
Audience
All Attendees
Session Category
Backend Development

It seems to be considered a worthwhile APP redesign, it must recover data from the old platform. Sometimes it is as simple as saying "A goes into A, B goes into B". Other times it is "A goes into A if X happens, but if Y happens it goes into B. B goes into C but only if Z happens". 

On a daily basis, I have not migrated much data, but projects in which those processes took place were not the easiest ones. In order to further develop, I will provide you with two experiences. 

For my first experience, we had almost 150 domains to migrate from a Drupal 7 to a Drupal 8 and around 20000 nodes and 3000 blocks. Following the feature’s needs and the time given, we chose Micro Site to replace Domains and all the blocks were transformed into paragraphs. What this means is that we were in a big case of “A goes into A if X happens, but if Y happens it goes into B. B goes into C but only if Z happens”. Almost every content had a condition for it to be migrated in one way or another.

As for my second experience, we migrated a Spring application to Drupal. It is of the utmost importance to know that Spring uses Neo4J, a graph type database, and our Drupal was using PostgreSQL. For this second use case, we chose to use Open Social and Groups. This time, I knew what we should do and what we should not do. But no one really knew neither what had already been implemented nor how it worked. 

In the end and in both cases, I discovered that usually the problems that occur during the process are the same. For that, the following questions come to my mind:

When must we be concerned about migration mapping? In what stage of the project? Do we know the old platform? Do we have access to it? Can we and should we use Migrate?

I encountered projects in which those questions or their possible answers came too late several times. 

I would like to end this talk by exposing the conclusions that I have recollected not only from my work experience, but also from my field colleagues. For example: how to try to integrate the migration as soon as possible or how to try to simplify your life with Migrate if the data is too complex. 

I hope my experience will bring a new point of view to what you already know and that it can be a moment of sharing! 

Speaker(s)
Profile picture for user Curried

Nerea Enrique

ekino
Speaker biography

PHP engineer since 2018. Loves PHP, PHP events, hiking and especially art..

Session Keywords
App-Development
Back End Development
PHP
Share:

Platinum Sponsors

Logo 1xinternet

Gold Sponsors

D shaped logo and the name Droptica
Logo AgileDrop
Logo Amazee.io

Silver Sponsors

Logo Kraut.Hosting GmbH
dropsolid logo
Logo EOR Digital GmbH
Logo Druid.fi

Media Partner

Logo Kurier.at
droptimes logo

Funded by

wko logo
Meeting Destination Vienna

Footer

  • Contact
  • Code of Conduct
  • Data Privacy
  • Media Policy
  • FAQs
  • Imprint

Copyright © Drupal Dev Days 2025. All rights reserved.

Webdesign by acolono GmbH, implementation by Alex Milkovskyi

Webhosting by amazee.io
Powered by Drupal