Drupal 7 지원 종료 2025: 엔터프라이즈 팀을 위한 마이그레이션 가이드
Drupal 7을 프로덕션 환경에서 계속 실행 중이라면, 말을 돌리지 않겠습니다: 당신은 빌린 시간을 쓰고 있습니다. Drupal 7은 2025년 1월 5일에 공식적으로 생명 주기를 종료했으며, 이는 원래 2021년 11월 마감일부터 여러 연장을 거쳤습니다. 더 이상 보안 패치가 없고, 커뮤니티 지원이 없으며, 마이그레이션을 다음 분기까지 미룰 수 있다고 가장할 수 없습니다. 저는 지난 몇 년 동안 여러 엔터프라이즈 팀을 이 정확한 상황을 통해 도와왔으며, 마지막 순간까지 기다린 팀들은 항상 더 많은 비용을 치렀습니다 — 돈, 스트레스, 그리고 기술 부채로. 이 가이드는 여전히 Drupal 7을 실행 중인 모든 엔지니어링 VP에게 건네고 싶은 모든 것입니다.
목차
- Drupal 7 생명 주기 종료가 실제로 의미하는 것
- 엔터프라이즈 팀이 계속 지연한 이유
- 2025년 마이그레이션 옵션
- 옵션 1: Drupal 10/11로 마이그레이션
- 옵션 2: 최신 프론트엔드를 사용한 헤드리스 전환
- 옵션 3: 헤드리스 CMS로 완전히 전환
- 옵션 4: 확장 지원 공급업체 (시간 구매)
- 마이그레이션 계획: 단계별 프레임워크
- 콘텐츠 마이그레이션 전략
- 비용 및 일정 추정
- 팀이 저지른 일반적인 실수
- FAQ
Drupal 7 생명 주기 종료가 실제로 의미하는 것
"생명 주기 종료"가 실제로 어떤 의미인지 정확히 말하겠습니다. 혼동이 많았기 때문입니다:
- 더 이상 보안 업데이트가 없습니다. Drupal 보안 팀은 Drupal 7 코어 또는 contrib 모듈에 대한 권고나 패치를 발행하지 않습니다. 내일 심각한 SQL 주입 취약점이 발견되면 당신이 알아서 해야 합니다.
- 더 이상 버그 수정이 없습니다. 깨진 것은 깨진 상태로 남아있습니다.
- Contrib 모듈 유지보수자가 이동하고 있습니다. 대부분은 이미 이동했습니다. 많은 인기 있는 Drupal 7 모듈은 수년 동안 업데이트되지 않았습니다.
- 호스팅 제공업체가 지원을 중단할 것입니다. Pantheon, Acquia, Platform.sh 모두 Drupal 7 호스팅 환경을 단계적으로 폐지하기 위한 일정을 발표했습니다. Acquia는 기존 고객을 위해 2026년까지 Drupal 7 지원을 연장했지만, 이는 유료 추가 사항이지 장기 솔루션이 아닙니다.
- PHP 호환성 문제가 누적될 것입니다. Drupal 7은 PHP 5.x용으로 만들어졌습니다. 패치를 적용하면 PHP 8.1에서 실행되지만, PHP 8.1 자체는 2025년 12월에 생명 주기를 종료합니다. 지원되지 않는 소프트웨어 위에 지원되지 않는 소프트웨어를 쌓게 됩니다.
보안 위험만으로도 조치를 취해야 합니다. 조직이 어떤 형태의 PII, 재무 데이터 또는 건강 정보를 처리한다면, 패치되지 않은 Drupal 7을 실행하는 것은 규정 준수 책임입니다. PCI DSS, HIPAA, SOC 2 — 모두 패치된 지원되는 소프트웨어를 유지해야 합니다.
엔터프라이즈 팀이 계속 지연한 이유
저는 이 대화를 수십 번 나눴습니다. 이유는 항상 다음 중 하나입니다:
- "우리의 Drupal 7 사이트는 잘 작동합니다." 맞습니다. 작동하지 않을 때까지. 코드는 1월 6일에 작동을 멈추지 않지만 위험 프로필이 극적으로 변합니다.
- "Drupal 8/9/10으로의 마이그레이션은 간단한 업그레이드가 아닙니다." 이것은 실제로 사실입니다. Drupal 6→7 업그레이드 경로와 달리 Drupal 7에서 최신 Drupal로 이동하는 것은 본질적으로 재구축입니다. 아키텍처가 근본적으로 다릅니다 — Symfony 기반, 설정 관리, Twig 템플릿. 맞춤 모듈은 포팅되지 않습니다.
- "우리는 15년 분의 콘텐츠와 맞춤 기능이 있습니다." 엔터프라이즈 Drupal 7 사이트는 일반적으로 많이 맞춤화되어 있습니다. 맞춤 모듈, Views 설정, 복잡한 분류 구조, 레거시 시스템과의 통합. 마이그레이션 범위는 진정으로 큽니다.
- "예산이 승인되지 않았습니다." 가장 정직한 답이며 가장 일반적입니다.
이러한 이유 중 어느 것도 사라지지 않았지만, 마감일은 도착했습니다. 그렇다면 실제로 무엇을 해야 할지 말씀드리겠습니다.
2025년 마이그레이션 옵션
당신은 4가지 현실적인 경로가 있습니다. 각각 장단점이 있습니다. 솔직하게 설명하겠습니다.
| 옵션 | 일정 | 비용 범위 | 최적 대상 | 위험 수준 |
|---|---|---|---|---|
| Drupal 10/11 | 6-18개월 | $200K-$1M+ | Drupal 생태계에 투자한 팀 | 중간 |
| 헤드리스 프론트엔드 + Drupal 백엔드 | 4-12개월 | $150K-$600K | 친숙한 CMS와 최신 UX를 원하는 팀 | 중간 |
| 헤드리스 CMS 마이그레이션 | 3-9개월 | $100K-$500K | Drupal을 완전히 떠날 준비가 된 팀 | 중간-높음 |
| 확장 지원 공급업체 | 즉시 | $30K-$100K/년 | 6-18개월 더 많은 계획 시간이 필요한 팀 | 낮음 (단기) |
옵션 1: Drupal 10/11로 마이그레이션
Drupal 10은 2025년 현재 안정적인 릴리스이며, Drupal 11은 2024년 중반에 출시되었고 채택이 증가하고 있습니다. 팀이 Drupal을 알고 콘텐츠 모델이 견고하며 생태계에 남아있기를 원한다면 이것이 가장 간단한 경로입니다.
하지만 "간단"이 "쉬운"을 의미하지는 않습니다.
마이그레이션이 실제로 포함하는 것
Drupal은 Drupal 7 데이터베이스에서 콘텐츠를 가져올 수 있는 Migrate API를 제공합니다. 제 경험상 일반적인 마이그레이션의 약 60-70%를 처리합니다. 나머지는 다음을 위한 맞춤 마이그레이션 플러그인입니다:
- 맞춤 필드 유형
- 복잡한 엔티티 참조
- Paragraphs (Paragraphs 모듈을 사용한 경우)
- 파일 및 미디어 자산
- URL 별칭 및 리디렉션
- 사용자 계정 및 역할
맞춤 모듈을 다시 작성해야 합니다. 포팅하지 않고 — 다시 작성합니다. Drupal 10/11은 완전히 다른 아키텍처를 사용합니다. hook_node_view()에 연결된 맞춤 모듈이 있었다면 이제 이벤트 구독자와 플러그인을 작성합니다.
// Drupal 7 - hook 기반
function mymodule_node_view($node, $view_mode, $langcode) {
if ($node->type == 'article') {
$node->content['custom_field'] = array(
'#markup' => '<div>' . custom_logic($node) . '</div>',
'#weight' => 10,
);
}
}
// Drupal 10/11 - OOP, Symfony 기반
namespace Drupal\mymodule\EventSubscriber;
use Drupal\core_event\NodeViewEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
class NodeViewSubscriber implements EventSubscriberInterface {
public static function getSubscribedEvents() {
return [NodeViewEvent::class => 'onNodeView'];
}
public function onNodeView(NodeViewEvent $event) {
$node = $event->getNode();
if ($node->bundle() === 'article') {
// 여기에 로직 추가
}
}
}
Twig 템플릿 계층도 PHPTemplate과 완전히 다릅니다. 모든 맞춤 테마를 재구축해야 합니다.
현실적인 일정
중간 규모 엔터프라이즈 사이트 (500-5,000페이지, 10-20개 콘텐츠 유형, 5-10개 맞춤 모듈)의 경우 9-15개월을 예상하세요. 여기에는 발견, 콘텐츠 모델링, 개발, 콘텐츠 마이그레이션, QA, 그리고 출시가 포함됩니다.
옵션 2: 최신 프론트엔드를 사용한 헤드리스 전환
이것은 흥미로워지는 부분이며, 솔직히 말해서 2025년에 대부분의 엔터프라이즈 팀에게 권장하는 접근입니다. Drupal을 콘텐츠 백엔드로 유지하되 (Drupal 10/11로 업그레이드), 최신 JavaScript 프레임워크로 프론트엔드를 구축합니다.
Drupal 10/11은 코어에 포함된 우수한 JSON:API 지원을 갖추고 있습니다. 콘텐츠를 구조화된 데이터로 노출하고 Next.js, Astro 또는 모든 프론트엔드 프레임워크로 사용할 수 있습니다.
이 접근이 잘 작동하는 이유
- 편집 팀이 Drupal의 관리 인터페이스를 유지합니다. 그들이 알고 있습니다. 그들이 이것에서 생산적입니다. 이를 제거하면 조직적 고통이 발생합니다.
- 프론트엔드가 극적으로 빨라집니다. 정적 생성, 엣지 캐싱, 최신 이미지 최적화 — Drupal의 렌더링 계층에 볼트온하기 어려운 것들.
- 점진적으로 마이그레이션할 수 있습니다. 새 프론트엔드를 기존 사이트 옆에 설치하고 한 번에 한 섹션씩 마이그레이션합니다.
우리는 Next.js와 Astro를 사용하여 여러 헤드리스 Drupal 프론트엔드를 구축했으며, 성능 개선이 상당합니다. 한 고객은 Next.js 프론트엔드와 ISR(점진적 정적 재생성)로 이동한 후 Largest Contentful Paint가 4.2초에서 0.8초로 떨어졌습니다.
// Drupal의 JSON:API에서 가져오는 Next.js 페이지
export async function getStaticProps({ params }) {
const res = await fetch(
`${process.env.DRUPAL_BASE_URL}/jsonapi/node/article?filter[field_slug]=${params.slug}&include=field_image,field_tags`
);
const data = await res.json();
return {
props: {
article: data.data[0],
included: data.included,
},
revalidate: 60, // ISR: 60초마다 재생성
};
}
next-drupal 패키지(Chapter Three 유지보수)는 미리보기 모드, 인증, 콘텐츠 유형 매핑에 대한 내장 지원으로 이를 더욱 쉽게 만듭니다.
함정
백엔드에서 여전히 Drupal 7을 Drupal 10/11로 마이그레이션해야 합니다. 해당 작업을 피할 수 없습니다. 하지만 프론트엔드 재구축에서 분리하고 있으므로 시퀀싱에서 더 많은 유연성을 갖습니다.
옵션 3: 헤드리스 CMS로 완전히 전환
때로는 올바른 방법은 Drupal을 완전히 떠나는 것입니다. 팀에 강한 Drupal 전문성이 없거나, Drupal 개발자 채용에 어려움을 겪고 있다면 (그리고 있을 것입니다 — 2020년 이후 Drupal 재능 풀이 상당히 축소되었습니다), 또는 콘텐츠 모델이 Drupal이 잘하는 것을 초과했다면, 헤드리스 CMS가 올바른 선택일 수 있습니다.
인기 있는 마이그레이션 대상
| CMS | 가격 (2025) | 최적 대상 | 콘텐츠 API | 학습 곡선 |
|---|---|---|---|---|
| Contentful | $300-$2,500+/월 | 큰 편집 팀 | GraphQL + REST | 중간 |
| Sanity | $99-$949+/월 (맞춤 엔터프라이즈) | 개발자 주도 팀 | GROQ + GraphQL | 낮음-중간 |
| Storyblok | $109-$449+/월 | 시각적 편집 필요 | REST + GraphQL | 낮음 |
| Strapi (자체 호스팅) | 무료 (자체 호스팅) / $29+/월 (클라우드) | 통제를 원하는 팀 | REST + GraphQL | 중간 |
| Payload CMS | 무료 (자체 호스팅) / $35+/월 (클라우드) | TypeScript 우선 팀 | REST + GraphQL | 중간 |
우리는 헤드리스 CMS 개발 실무를 통해 여러 팀과 함께 작업합니다. 올바른 선택은 팀의 기술 능력, 콘텐츠 복잡성, 그리고 예산에 따라 달라집니다.
Drupal 7에서 헤드리스 CMS로의 콘텐츠 마이그레이션
이것은 어떤 면에서는 Drupal 10/11로의 마이그레이션보다 더 쉽습니다. Drupal의 마이그레이션 프레임워크에 제약을 받지 않습니다. 일반적인 접근:
- Drush를 통하거나 직접 데이터베이스 쿼리를 통해 Drupal 7 콘텐츠 내보내기
- 스크립트를 사용하여 대상 CMS의 콘텐츠 모델로 데이터 변환 (Python과 Node.js 모두 작동)
- CMS의 관리 API를 통해 가져오기
- 참조, 미디어, 그리고 관계 확인 및 수정
# 데이터베이스를 통한 간단한 Drupal 7 콘텐츠 내보내기
import mysql.connector
import json
db = mysql.connector.connect(
host="localhost",
user="drupal",
password="yourpassword",
database="drupal7_db"
)
cursor = db.cursor(dictionary=True)
cursor.execute("""
SELECT n.nid, n.title, n.created, n.changed, n.status,
fdb.body_value, fdb.body_summary
FROM node n
LEFT JOIN field_data_body fdb ON n.nid = fdb.entity_id
WHERE n.type = 'article' AND n.status = 1
ORDER BY n.created DESC
""")
articles = cursor.fetchall()
with open('articles_export.json', 'w') as f:
json.dump(articles, f, default=str, indent=2)
print(f"Exported {len(articles)} articles")
어려운 부분은 내보내기가 아닙니다. Drupal 7의 콘텐츠 모델 (필드 시스템, 엔티티 참조, 분류 용어, 그리고 Paragraphs 포함)을 새 CMS의 데이터 구조로 매핑하는 것입니다. 이것이 상당한 분석 시간을 걸릴 것으로 계획하세요.
옵션 4: 확장 지원 공급업체 (시간 구매)
더 많은 시간이 필요하다면 — 그리고 때로는 필요합니다, 특히 예산 주기와 조직 우선순위가 있을 때 — 확장 지원 공급업체는 당신이 계획하는 동안 Drupal 7 사이트를 패치된 상태로 유지할 수 있습니다.
Drupal 7 확장 지원을 제공하는 주요 공급업체
- Tag1 Consulting — 가장 확립된 것 중 하나. 보안 패치를 백포팅하고 진행 중인 유지보수를 제공합니다. 가격은 사이트 복잡성에 따라 다르지만 연간 $30K-$80K를 예상합니다.
- Acquia — 플랫폼을 통해 확장된 Drupal 7 지원을 제공하며, 현재 엔터프라이즈 고객을 위해 2026년까지입니다.
- mySociety / D7 LTS 기여자 — Drupal 7 확장 지원 프로그램을 통한 커뮤니티 주도 확장 지원.
이것은 합법적인 가교 전략이지만 장기 솔루션이 아닙니다. 최대 12-18개월로 한정하겠습니다. Drupal 7에 머물고 있는 매달 D7과 최신 플랫폼 간의 격차가 넓어지면서 마이그레이션 복잡성이 증가합니다.
마이그레이션 계획: 단계별 프레임워크
여기는 모든 엔터프라이즈 마이그레이션에 사용하는 프레임워크입니다. 화려하지는 않지만 작동합니다.
1단계: 감사 (2-4주)
- 콘텐츠 감사: 콘텐츠 유형이 몇 개입니까? 유형당 노드는 몇 개입니까? 콘텐츠 모델 복잡성은 어떻습니까? Paragraphs, Field Collections, Entity Reference를 사용하고 있습니까?
- 모듈 감사: 모든 contrib과 맞춤 모듈을 나열합니다. 분류: D10 동등물이 있음, 맞춤 교체 필요, 제거 가능.
drush pm:list --status=enabled를 사용하고 drupal.org와 교차 참조합니다. - 통합 감사: Drupal이 말하는 외부 시스템은 무엇입니까? 결제 게이트웨이, CRM, 마케팅 자동화, SSO 제공자?
- 트래픽 및 성능 기준선: 현재 성능 메트릭을 문서화합니다. 비교를 위해 이것들이 필요합니다.
- 사용자 역할 감사: 편집 워크플로우가 몇 개입니까? 어떤 권한이 중요합니까?
2단계: 아키텍처 결정 (2-3주)
감사를 기반으로 4가지 옵션 중 어느 것이 맞는지 결정합니다. 이것은 엔지니어링 리더십, 콘텐츠 이해관계자, 그리고 예산을 통제하는 사람이 포함되어야 하는 진정한 아키텍처 결정입니다.
3단계: 개념 증명 (3-6주)
전체 마이그레이션에 커밋하기 전에 다음을 다루는 개념 증명을 구축하세요:
- 새 플랫폼으로 마이그레이션된 2-3개 콘텐츠 유형
- 가장 복잡한 편집 워크플로우 재현
- 하나의 중요 통합이 연결됨
- 새 스택의 성능 벤치마크
이것이 감사 중에 아무도 언급하지 않은 것들을 발견하는 곳입니다. 항상 뭔가가 있습니다.
4단계: 완전 마이그레이션 (3-12개월)
이것이 실제 작업입니다. 무자비하게 우선순위를 정하세요. Drupal 7의 일반적인 엔터프라이즈 사이트의 콘텐츠와 기능의 20-30%가 마이그레이션 중에 제거될 수 있습니다.
5단계: QA 및 출시 (2-4주)
리디렉션이 중요합니다. 검색 자산이 있는 Drupal 7 사이트의 모든 URL은 새 사이트로 301 리디렉션이 필요합니다. path_redirect와 globalredirect 모듈 내보내기를 시작점으로 사용한 다음 Screaming Frog로 이전 사이트를 크롤링하여 완전한 리디렉션 맵을 작성합니다.
콘텐츠 마이그레이션 전략
콘텐츠 마이그레이션은 자체 섹션을 구성할 자격이 있습니다. 대부분의 마이그레이션이 여기서 벗어나기 때문입니다.
본문 필드 문제
Drupal 7 본문 필드는 일반적으로 HTML로 혼란스럽습니다. 인라인 스타일, 하드코드된 이미지 경로, 포함된 iframe, 그리고 때때로 원본 PHP (누군가 PHP 필터 모듈을 활성화한 경우 — 진정한 보안 공포)를 찾을 수 있습니다. 마이그레이션 전에 다음을 결정해야 합니다: 정리하거나, 혼란을 포팅하세요?
제 권장사항: 정리하세요. 다음을 수행하는 변환 스크립트를 작성하세요:
- 인라인 스타일 제거
<img>태그를 적절한 미디어 참조로 변환- 내부 링크를 새 URL 구조로 수정
- WYSIWYG 포함 토큰을 새 형식으로 변환
미디어 마이그레이션
Drupal 7 사이트는 매우 다른 방식으로 미디어를 처리합니다. 일부는 Media 모듈(1.x 또는 2.x)을 사용하고, 일부는 일반 파일 필드를 사용하고, 일부는 본문 필드에 포함된 미디어 토큰을 사용합니다. 마이그레이션 코드 작성을 시작하기 전에 모든 미디어 처리 패턴을 매핑합니다.
헤드리스 CMS로 이동하는 경우 미디어 파일이 어디에 있는지도 결정해야 합니다. 대부분의 헤드리스 CMS는 내장 자산 관리를 가지고 있거나 Cloudinary 또는 imgix와 같은 DAM을 사용할 수 있습니다.
다국어 콘텐츠
Drupal 7 사이트가 i18n, entity_translation, 또는 content_translation을 사용한다면 마이그레이션 복잡성이 대략 두 배가 됩니다. Drupal 7의 다국어 시스템은... 창의적이라고 부르겠습니다. 데이터 구조가 일관성이 없으며 신중한 매핑이 필요합니다.
비용 및 일정 추정
저는 관여했거나 직접 알고 있는 프로젝트를 기반으로 실제 숫자를 제시합니다.
| 사이트 복잡성 | Drupal 10/11 마이그레이션 | 헤드리스 CMS 마이그레이션 | 헤드리스 프론트엔드 + Drupal 백엔드 |
|---|---|---|---|
| 소형 (5-10개 콘텐츠 유형, <1K 페이지, 2-3개 맞춤 모듈) | $80K-$150K, 3-6개월 | $60K-$120K, 2-4개월 | $100K-$180K, 3-6개월 |
| 중형 (10-20개 콘텐츠 유형, 1K-10K 페이지, 5-10개 맞춤 모듈) | $200K-$500K, 6-12개월 | $150K-$350K, 4-8개월 | $200K-$450K, 5-10개월 |
| 대형 (20+ 콘텐츠 유형, 10K+ 페이지, 10+ 맞춤 모듈, 다국어) | $500K-$1.5M+, 12-24개월 | $300K-$800K, 6-14개월 | $400K-$1M+, 8-18개월 |
이는 발견, 개발, 마이그레이션, QA, 프로젝트 관리를 포함한 완전하게 로드된 비용입니다. 팀 구성(사내 vs. 에이전시), 지리적 위치, 정리하는 방법 vs. 그대로 포팅하는 방법에 따라 달라질 수 있습니다.
귀하의 상황에 더 구체적인 추정치를 원하신가요? 우리는 마이그레이션 평가를 수행합니다. 이는 범위와 비용을 명확히 이해할 수 있도록 합니다.
팀이 저지른 일반적인 실수
1:1 재창조를 시도하고 있습니다. Drupal 7 사이트는 10년 이상의 때가 축적되었습니다. 모두 마이그레이션하지 마세요. 마이그레이션을 단순화할 기회로 사용하세요.
리디렉션 노력을 과소평가하고 있습니다. 저는 팀이 출시 2주 전까지 리디렉션을 잊어버린 마이그레이션에 참여했습니다. 그들은 45,000개의 URL을 매핑해야 했습니다. 그 팀이 되지 마세요.
편집 이해관계자를 충분히 일찍 포함하지 않습니다. CMS를 매일 사용하는 사람들은 새 시스템에 대해 강한 의견을 가질 것입니다. 4단계가 아닌 1단계에 참여시키세요.
팀 능력이 아닌 기능을 기반으로 플랫폼을 선택합니다. 최고의 CMS는 팀이 실제로 유지보수할 수 있는 것입니다. Drupal 전문성이 없다면 Drupal 10/11로의 마이그레이션이 5년 내에 이 상황의 반복을 설정하고 있습니다.
병렬 시스템을 너무 오래 실행합니다. 하드 절환 날짜를 설정합니다. 구식과 신식을 병렬로 실행하는 것은 비싸고 혼란스럽습니다.
콘텐츠 동결을 건너뜁니다. 최종 마이그레이션 푸시 중에 구식 사이트에서 콘텐츠 동결이 필요합니다. 계획하세요. 전달하세요. 콘텐츠 작성자가 싫어하지만 필요합니다.
FAQ
생명 주기 종료 후 Drupal 7을 계속 실행하면 어떻게 됩니까?
사이트가 갑자기 작동 정지를 멈추지 않습니다. 하지만 보안 패치를 받지 못하므로 새로 발견된 모든 취약점은 무기한으로 패치되지 않은 상태로 유지됩니다. 이것은 실제 위험입니다 — Drupal 사이트는 자동화된 공격의 빈번한 대상입니다. PHP 버전이 발전하고 호스팅 제공자가 구형 PHP 버전에 대한 지원을 중단함에 따라 호환성 문제가 증가합니다. PCI, HIPAA, SOC 2, GDPR과 같은 규정 준수 요구 사항이 있는 모든 조직의 경우 지원되지 않는 소프트웨어를 실행하는 것은 직접적인 위반입니다.
Drupal 7에서 Drupal 11로 직접 업그레이드할 수 있습니까?
예, Migrate API는 Drupal 7에서 Drupal 10 또는 11로의 직접 마이그레이션을 지원합니다. Drupal 8과 9를 통해 단계를 밟을 필요가 없습니다. 하지만 이것은 전통적 의미의 "업그레이드"가 아닙니다 — 콘텐츠가 마이그레이션되는 새 플랫폼에서 사이트를 재구축하는 것입니다. 테마, 맞춤 모듈, 설정은 직접 전달되지 않습니다.
일반적인 Drupal 7 마이그레이션은 얼마나 걸립니까?
중간 규모 엔터프라이즈 사이트의 경우 킥오프에서 출시까지 6-12개월을 계획하세요. 제한된 맞춤 기능이 있는 더 작은 사이트는 3-4개월에 수행할 수 있습니다. 다국어 콘텐츠, 광범위한 통합, 무거운 맞춤화가 있는 크고 복잡한 사이트는 12-24개월가 걸릴 수 있습니다. 감사 단계는 특정 상황에 대해 훨씬 더 정확한 추정치를 제공할 것입니다.
Drupal 10/11로 마이그레이션하거나 CMS 플랫폼을 전환하는 것이 가치가 있습니까?
팀과 필요에 따라 달라집니다. 사내에 Drupal 전문성이 있고, 콘텐츠 모델이 Drupal의 엔티티 시스템에 적합하며, Drupal의 강점이 필요한 경우 (복잡한 권한, 다국어, 멀티사이트), 생태계에 머물러있는 것이 합리적입니다. Drupal 개발자 채용에 어려움을 겪고 있다면, 사이트가 주로 복잡한 편집 워크플로우가 없는 마케팅 사이트이거나 헤드리스 아키텍처로 이동하고 싶다면 다른 CMS이 더 나은 투자일 수 있습니다.
Drupal 7에서 마이그레이션할 가장 저렴한 옵션은 무엇입니까?
Tag1 ($30K-$80K/년)과 같은 공급업체의 확장 지원이 가장 저렴한 단기 옵션이지만 근본적인 문제를 해결하지 못합니다. 실제 마이그레이션의 경우 더 간단한 사이트의 경우 정적 프론트엔드를 사용하여 Sanity 또는 Storyblok과 같은 헤드리스 CMS로 이동하는 것이 가장 비용 효과적인 경로인 경향이 있으며 약 $60K-$120K로 시작합니다. 가격에 대한 자세한 내용은 가격 페이지를 확인하세요.
마이그레이션으로 SEO 순위가 영향을 받습니까?
그럴 수 있지만 적절한 계획은 영향을 최소화합니다. 중요한 요소는: URL 구조 유지 (또는 모든 인덱싱된 URL에 대한 적절한 301 리디렉션 구현), 메타 데이터 및 구조화된 데이터 마크업 유지, 새 사이트가 구식 사이트만큼 적어도 빠르게 로드 (이상적으로 더 빠르게), Google Search Console에 업데이트된 사이트맵 제출. 좋은 실행 마이그레이션은 더 좋은 페이지 속도와 모바일 경험으로 인한 SEO 개선으로 이어지는 경우를 봤습니다. 리디렉션을 잊었기 때문에 마이그레이션이 망가진 경우 트래픽이 50% 떨어지는 것을 본 적도 있습니다.
콘텐츠를 점진적으로 마이그레이션하거나 한 번에 모두 해야 합니까?
점진적 마이그레이션이 가능하며 종종 대규모 사이트에 권장됩니다. 헤드리스 아키텍처를 사용하면 새 프론트엔드를 설치하고 섹션별로 사이트의 섹션을 한 번에 마이그레이션할 수 있으며 역프록시 규칙을 사용하여 적절한 백엔드로 트래픽을 라우팅합니다. 이는 위험을 줄이고 각 섹션을 앞으로 이동하기 전에 검증할 수 있도록 합니다. 이점은 마이그레이션 기간 동안 증가된 운영 복잡성입니다.
WordPress를 마이그레이션 대상으로 고려해야 합니까?
WordPress는 더 간단한 사이트의 경우 실행 가능한 옵션이지만 엔터프라이즈 사용 사례는 조심하겠습니다. Drupal 7 사이트에 복잡한 콘텐츠 유형, 세밀한 권한, 또는 정교한 편집 워크플로우가 있는 경우 WordPress는 다운그레이드처럼 느껴질 것입니다. WordPress의 콘텐츠 모델 (게시물, 페이지, 맞춤 게시물 유형)은 Drupal의 엔티티 시스템보다 간단합니다. 엔터프라이즈 팀의 경우 Drupal 10/11 또는 적절한 헤드리스 CMS를 더 진지하게 살펴보겠습니다. 즉, ACF Pro와 헤드리스 프론트엔드를 사용한 WordPress는 마케팅 중심 사이트에서 잘 작동할 수 있습니다.