Moving from a self-written site to Drupal: migrating tens of thousands of users and tons of content. Upgrade future functionality without huge development costs.

Websites can be created either on off-the-shelf platforms (WordPress, Tilda, Drupal) or self-written - where the developer (expectedly) writes the code himself, which turns into a website. At some point, such an undertaking becomes too expensive: the programmer has to hollow out code for any, even the simplest request. There are no off-the-shelf solutions for self-writing, as there are for well-known platforms․

Our clients came to us with just such a website. Their task at that time could have cost 200 hours of development time, compared to 50 hours for the same task with Drupal. So we offered them migration and development prospects, but first things first.

In this article we will talk about how we migrated from self-written website, which features Drupal gives to website with a lot of content and what benefits come with moving to Drupal in general.

The client and his task

Our client is a "social network" of traumatologists, orthopedists and surgeons calcaneus.ru. On their site, specialists from all over Russia publish thematic articles, share their experiences and communicate. As we have already said, the site is made with pure code. No content management system for admins, no customary engine for mere mortals - only code.

And in essence, the owners could implement anything they wanted. But it was getting more and more expensive and longer to add the necessary functionality to the self-descriptor.

A customer asked for a calendar of events to be added to the site. So that users could sign up for online and offline events, receive notifications about them, etc. During evaluation we found out that the task will take 200 hours, although Drupal has ready modules for this. They don't need to be re-written and are much faster to implement - about 50 hours. Plus a conversation with the client made it clear that they were planning further development and new features, which could take much more time. We suggested an optimal solution: move to Drupal to save time, effort and money (this trinity sounds trivial, but it is).

A content site needs Drupal

But we're not us if we don't talk about the benefits of Drupal.

Let's stipulate: in the beginning, making a self-written site wasn't the worst solution, everything according to MVP (minimum viable product) rules: sketch an inexpensive prototype, test the performance and demand. But once the positive impact happened, you have to think about more rational development.

Our main argument for this client was simple: you have a content website. Several thousand articles, user profiles, a calendar in the future. And Drupal is literally designed to handle content:

• build collections of articles
• search for articles
• interact with workflow: save drafts, moderate articles, etc.

And all this can be done with a mouse in the admin by a minimally trained person, instead of a programmer getting into the code. On top of that:

• Mass operations on users: ban, give a new status;
• tools for moderation of comments and content;
• easier to collect reports: how many comments were added over a period of time;
• in the future, it is easier to implement analytics.

A content site needed a content management system, and there wasn't one. The self-written code did the minimum necessary, but the new functionality needed a programmer who knows the site well and who would complete it.

Stages of work

Here is the order in which we acted.

3. We wrote the migration.Conventionally match paths between where we took the old values from and where we need to write to the new site. For all entities on the site the path is written: username was here, migrate it here, etc. In the same way we need to translate:

• comments
• likes;
• user profiles, user favourites.

This was the first time we had done a user migration with passwords saved. The difficulty was that the self-written site and Drupal have different encryption systems. We didn't have passwords in plaintext, so we had to recode them from one system to the other. We succeeded, so all the users continued to use the site under their accounts.

4. imported the content into the site.Another snag: The content was not homogeneous. For instance, in the process of developing the project, the system of uploading pictures was changed. Therefore, in a part of articles pictures were stored in one way and in a part of newer articles in another. This had to be taken into account when migrating the articles. So there was quite a lot of manual work on the data, which was poorly imported.

We migrated users, articles, comments under articles, article ratings, favourite articles, favourite contacts and more.

We also did a lot of work on changing the Drupal admin, so that users and editors would be in a familiar environment after the migration. Usually customers are not interested in this, because only employees or developers are dealing with the back-end. In this case, user comfort was at stake, so the team of designers, frozen in usability, had fun with remaking Drupal admin panel to look like self-written one. The familiar Drupal look remained only for the super-admins who code.

At the same stage we implemented event calendar.

5. Launch.We shut down the old site from writing for three days, to prevent new content from forming there. We re-uploaded all the files, uploaded them to our empty site, tested and launched. Switched the domain, set up the infrastructure, the server. Picked up a copy to implement changes in the future.

Bonus:in parallel with the migration, we did a small redesign at the customer's request. The users didn't really notice the change - they were just unlogged, and re-logged into a slightly updated site.

Result:At the time of writing, the site has been online for a month without any serious errors. Users continue to come in, register, administrators publish articles. Life goes on as usual.

Conclusions and development prospects

In the future, the client wants to implement the functionality for selling online courses. In addition, the customer has a website, which is being developed in parallel. It is also planned to move it to Drupal and multisiting, leaving a single code base, but with different content, to introduce new functions on the second site in parallel.

And that's not all. But even considering only these development plans, Drupal will definitely be cheaper. The second plus is reliability. All the modules needed for development are stable and well-tested, with fewer bugs and errors. Coding new features from scratch is, roughly speaking, reinventing the wheel. Uniform standardized content. And no abuse.