Secondary menu

Why your site from 1996 should not be ported to Drupal without a redesign

j's picture

Why your site from 1996 should not be ported to Drupal without a redesign

Written by Jonathan Lambert on

In the past year, we've worked with a number of fantastic clients. One of the things we've seen repeatedly is a desire by some clients to do work that is a "port" of the existing site to Drupal technologies. This is often not the right approach.

1) First, and in most cases, a port will not help to improve your revenue outcomes, or reach your user goals. Each site iteration is an opportunity to introduce improvements from the learning that has gone on during the previous site's lifetime. Denying yourself the opportunity to improve site outcomes relegates the exercise of implementing the new site to an effort to simply keep your current traffic and site goals from dropping — a difficult thing to avoid if you're having to undo mistakes done previously. And if you haven't improved the site, you have no better outcome possibilities than simply maintaining your current traffic, conversion, and other metrics.

2) Second, a redesign is usually not that much more expensive. Drupal has native functionality, and it wants to work like Drupal is designed to work. Restrictive layouts, common in the more "portal oriented" designs that dominated the previous generation of sites, require a great deal of theme work (the front-end), as well as sometimes requiring support for engineering overlays that can radically increase the cost of implementation. Generally, a very small number of features generate the majority of traffic to a site. Your job is to discover, build properly, and promote those features. It's the 80/20 rule all over again, and guess what? It's still true. Sticking to conventions that are friendly to Drupal tends to lead to a less expensive implementation, with less risk, and a greater outcome.

3) Third, not every aspect of a given site is worth updating. Many times, features will come in as part of a project that have little to no serious traffic. Often these features were built as part of various marketing or sales efforts, or have been retained "just because they're there." However, if a feature costs actual dollars to implement, but produces no outcome, and you know it, do not port it. The exercise we repeatedly do with clients — which we consider just as important as deciding what and how to port — is identifying features from an old property that are worth eliminating. What you eliminate is just as important as what you port.

One of the most important things you can consider is:

Before investing in a new site, which is critical to your business, it's critical to evaluate why you are redesigning your site, and why you are redesigning right now. If you know why you're doing it, and you keep the focus on core features, that generate revenue and engagement, and cut anything and everything that isn't a contributor to those two points, you're well on your way to a successful outcome.

Many platforms built in the post dot-com era are built on custom systems. Many are custom PHP or ASP applications that have become bloated or "feature driven" (rather than customer or business need driven) over time. If you're porting one of these applications, you should seriously consider these points.

So, to summarize:

  • Learn from your mistakes Do take advantage of an update to apply lessons learned
  • Redesign it Consider redesigning instead of just a replatform. Don't segment these steps — you will pay more ultimately for what you could have had for less
  • Cut hard. Reduce, eliminate, and cut features that are not used aggressively (avoid "porting creep")
  • Define success. Make sure that your engineering work has specific, measurable, business affecting outcomes
  • Avoid Feature Bloat If you're finding yourself looking at Reddit, Youtube, Facebook, or another site and thinking it should be a "feature" of your new site, think again. Focus is everything, and you should really make sure that you nail a tightly focused site — everything from the UI to the implementation is easier, and comes more naturally. Not to mention the focus on features tends to become addictive — and expensive.

I welcome your comments and reactions.