TYPO3에서 Headless CMS로의 마이그레이션: 실무 개발자 가이드
TYPO3를 상당한 시간 동안 사용해본 개발자라면 이것이 얼마나 강력한 플랫폼인지 알 것입니다. 나쁜 의미는 아니지만 -- 특히 복잡한 콘텐츠 구조, 다국어 설정, 그리고 세분화된 권한이 필요한 대규모 유럽 기업 사이트에는 정말 강력합니다. 그러나 TYPO3를 운영하는 팀들 사이에서는 점점 더 커지는 깨달음이 있습니다: 모놀리식 아키텍처가 그들을 막고 있다는 것입니다. 프론트엔드 개발자는 React나 Vue를 사용하고 싶어 합니다. 마케팅 팀은 옴니채널 콘텐츠 전달을 원합니다. DevOps는 더 간단한 배포를 원합니다. 그리고 모두가 더 나은 성능을 원합니다.
이것이 헤드리스 CMS 마이그레이션의 역할입니다. 저는 TYPO3에서 헤드리스 아키텍처로 조직을 이동시키는 이 프로세스를 여러 번 거쳤습니다. 솔직히 말해서, 그것은 공급업체 마케팅 페이지에서 시사하는 것만큼 간단하지 않습니다. 하지만 조건이 맞을 때 이를 수행할 가치는 절대적으로 있습니다. 이 가이드는 TYPO3에서 헤드리스 CMS로 마이그레이션하는 데 관련된 실제 결정, 위험, 그리고 전략을 다룹니다.
목차
- 팀이 TYPO3를 떠나는 이유
- 마이그레이션이 실제로 의미가 있을 때
- 헤드리스 CMS 선택
- 콘텐츠 모델링: 어려운 부분
- 데이터 마이그레이션 전략
- 프론트엔드 아키텍처 결정
- TYPO3 고유 기능 처리
- 마이그레이션 중 SEO 보존
- 테스트 및 런칭 전략
- 실제 마이그레이션 타임라인 및 비용
- FAQ
팀이 TYPO3를 떠나는 이유
명확히 하겠습니다: TYPO3는 나쁜 소프트웨어가 아닙니다. 성숙하고, 잘 유지보수되며, 특히 독일, 오스트리아, 스위스에서 헌신적인 커뮤니티를 가지고 있습니다. 하지만 규모에 따라 고통스러워지는 특정 아키텍처 제약을 가지고 있습니다.
개발자 경험의 마찰
TYPO3의 템플릿 시스템(Fluid)은 강력하지만 틈새시장입니다. Fluid, TypoScript, Extbase/TYPO3 확장 프레임워크를 아는 개발자를 찾기가 점점 더 어려워지고 있습니다. 학습 곡선은 가파르고, 젊은 개발자들은 JavaScript 프레임워크로 작업하기를 압도적으로 선호합니다. 팀이 TYPO3에 정통한 개발자를 찾을 수 없어 채용 타임라인이 두 배로 늘어난 사례를 봤습니다.
성능 제한
TYPO3는 PHP를 통해 서버 측에서 페이지를 렌더링합니다. 캐싱이 도움이 되지만, 기본적으로 모놀리식 요청 사이클에 의해 제한됩니다. 정적 사이트 생성 및 에지 렌더링 -- 현대 프레임워크가 잘하는 것들 -- TYPO3의 아키텍처에 기본적으로 제공되지 않습니다. TYPO3 Headless 확장(EXT:headless)은 TYPO3를 API로 변환하지만, 이 시점에서 당신은 실제 작업을 점점 더 적게 하는 PHP 백엔드를 유지해야 합니다.
콘텐츠 재사용 문제
TYPO3의 콘텐츠 모델은 페이지 중심입니다. 콘텐츠 요소는 페이지에 있습니다. 모바일 앱, 디지털 키오스크, 이메일 시스템, 그리고 웹사이트에 동시에 콘텐츠를 전달해야 하는 경우, TYPO3의 모델은 매 단계마다 당신과 싸웁니다. 헤드리스 CMS 플랫폼은 처음부터 콘텐츠를 구조화된 데이터로 취급하므로, 다중 채널 전달이 부착된 것이 아닌 자연스럽습니다.
총 소유 비용
TYPO3를 실행하는 것은 PHP 서버를 유지하고, TYPO3 코어 업데이트를 관리(주요 버전 사이에 상당할 수 있음)하고, 확장 호환성을 유지하는 것을 의미합니다. 헤드리스 SaaS CMS는 대부분의 인프라 오버헤드를 제거합니다. Strapi나 Directus와 같은 자체 호스팅 헤드리스 옵션도 일반적으로 운영 노력이 덜 필요합니다.
마이그레이션이 실제로 의미가 있을 때
모든 TYPO3 사이트가 헤드리스로 이동해야 하는 것은 아닙니다. 제 솔직한 평가입니다:
| 시나리오 | 마이그레이션? | 이유 |
|---|---|---|
| 간단한 소개 사이트, 50개 페이지, 한 언어 | 아마도 아니오 | 과도합니다. TYPO3는 여기서 잘 작동합니다. |
| 모바일 앱이 있는 다국어 기업 사이트 | 예 | 헤드리스는 옴니채널 전달에서 빛납니다 |
| 복잡한 제품 데이터가 있는 전자상거래 | 예 | 더 나은 프론트엔드 유연성, API 우선 통합 |
| 수많은 TYPO3 확장(news, events, forms)이 있는 사이트 | 아마도 | 먼저 확장 종속성을 감사합니다 |
| TYPO3 백엔드 워크플로우가 있는 내부 포털 | 주의 | 대체하기 어려운 워크플로우 기능을 잃을 수 있습니다 |
| 팀이 TYPO3 개발자를 고용할 수 없음 | 예 | 지속 가능성이 기능보다 더 중요합니다 |
마이그레이션은 이미 재설계 또는 플랫폼 업그레이드를 계획하고 있을 때 가장 의미가 있습니다. 순수하게 기술적 이유로 마이그레이션하면 -- 비즈니스 트리거 없이 -- 예산 승인을 받기 어려운 경우가 많습니다.
헤드리스 CMS 선택
이것이 팀이 막히는 지점입니다. 수십 개의 헤드리스 CMS 옵션이 있으며, 올바른 선택은 당신의 특정 상황에 크게 달려 있습니다.
엔터프라이즈급 옵션
Contentful은 여전히 엔터프라이즈 헤드리스 CMS 시장 리더입니다. 가격은 Team 플랜의 경우 약 $300/월에서 시작하여 맞춤 엔터프라이즈 가격으로 확장됩니다(일반적으로 사용량에 따라 $2,000-$10,000+/월). 성숙하고 잘 문서화되어 있으며 훌륭한 SDK가 있습니다. 콘텐츠 모델링은 유연하며, Compose 기능은 TYPO3 편집자가 익숙한 페이지 빌딩 사용 사례를 처리합니다.
Sanity는 개발자 경험 측면에서 제 개인적인 선호도입니다. 가격 모델은 관대합니다 -- 무료 티어는 많은 소규모 프로젝트를 처리하고, Team 플랜의 경우 $15/사용자/월입니다. Sanity Studio는 React로 완전히 사용자 정의할 수 있으므로, TYPO3의 백엔드를 능가하는 편집 경험을 구축할 수 있습니다. GROQ 쿼리 언어는 익숙해지는 데 시간이 걸리지만, 일단 익숙해지면 매우 강력합니다.
Storyblok은 TYPO3 마이그레이션을 위해 특별히 주목할 가치가 있습니다. TYPO3 백엔드 사용자에게 익숙한 느낌의 시각적 편집기를 제공하기 때문입니다. 가격은 Entry 플랜의 €99/월에서 시작합니다. DACH 지역에서 특히 인기가 있으며, 이는 TYPO3의 사용자 기반과 크게 겹칩니다.
오픈소스 대안
Strapi(2024년 v5 릴리즈)는 선도적인 오픈소스 옵션입니다. 자체 호스팅하거나 Strapi Cloud(좌석당 $29/월부터 시작)를 사용할 수 있습니다. Node.js 기반이며 PostgreSQL 또는 MySQL 데이터베이스를 사용하고, 빠르게 성장하는 플러그인 생태계를 제공합니다.
Directus는 모든 SQL 데이터베이스에 API와 관리 패널을 래핑합니다. 기존 데이터베이스 구조를 유지하고 점진적으로 마이그레이션하려는 경우 좋은 선택입니다. 오픈소스 버전은 완전히 기능하며, 클라우드 버전은 $99/월에서 시작합니다.
비교 표: TYPO3 마이그레이션을 위한 헤드리스 CMS 옵션
| 기능 | Contentful | Sanity | Storyblok | Strapi | Directus |
|---|---|---|---|---|---|
| 호스팅 모델 | SaaS | SaaS + 자체호스팅 | SaaS | 자체호스팅 + 클라우드 | 자체호스팅 + 클라우드 |
| 시각적 편집기 | Compose(추가 기능) | 사용자 정의 가능 | 내장 | 플러그인 | 제한적 |
| 다국어 | 우수 | 좋음 | 우수 | 좋음 | 좋음 |
| 시작 가격 | $300/월 | 무료 티어 | €99/월 | 무료(OSS) | 무료(OSS) |
| TYPO3 편집자 친숙성 | 중간 | 낮음 | 높음 | 중간 | 중간 |
| 콘텐츠 모델링 | 유연함 | 매우 유연함 | 컴포넌트 기반 | 유연함 | 데이터베이스 중심 |
| 웹훅/워크플로우 | 예 | 예 | 예 | 예 | 예 |
우리는 헤드리스 CMS 개발 서비스를 통해 이 대부분의 플랫폼과 함께 작업합니다. 선택은 편집자가 시각적 편집 경험이 필요한지(Storyblok, Contentful Compose) 또는 개발자 유연성이 우선인지(Sanity, Strapi)에 따라 종종 결정됩니다.
콘텐츠 모델링: 어려운 부분
대부분의 마이그레이션이 문제를 겪는 지점은 여기입니다. TYPO3의 콘텐츠 모델은 기본적으로 헤드리스 CMS 콘텐츠 모델과 다르며, 하나를 다른 하나에 단순히 매핑할 수 없습니다.
TYPO3의 콘텐츠 구조 이해
TYPO3에서 콘텐츠는 다음과 같이 구성됩니다:
- 페이지(페이지 트리) - 속성과 메타데이터 포함
- 콘텐츠 요소(tt_content) - 페이지의 열에 배치됨
- 확장 - 사용자 정의 레코드 타입 추가(news, events 등)
- 카테고리 및 파일 참조 - sys_file_reference 테이블을 통해 연결됨
- TypoScript - 렌더링 및 데이터 흐름에 영향을 미치는 구성
이것은 페이지 우선 모델입니다. 콘텐츠는 페이지의 컨텍스트 내에 존재합니다.
헤드리스 콘텐츠 모델링
헤드리스 CMS 플랫폼은 콘텐츠 우선 모델을 사용합니다. 콘텐츠 타입(예: Article, Author, Product)을 필드와 함께 정의하고, 그 다음 이러한 콘텐츠 항목에 대한 참조로부터 페이지를 구성합니다. 페이지 자체는 종종 또 다른 콘텐츠 타입일 뿐입니다.
번역 작업은 다음과 같이 보입니다:
TYPO3 페이지 트리 → slug/계층 필드가 있는 Page 콘텐츠 타입
tt_content (text) → Rich text 컴포넌트/블록
tt_content (image) → asset 참조가 있는 Media 컴포넌트
tx_news_domain_model_news → Article/News 콘텐츠 타입
카테고리 (sys_category) → Tags/Categories 콘텐츠 타입
파일 참조 → 에셋 관리(DAM)
실제 조언
TYPO3의 콘텐츠 모델을 헤드리스 CMS에 복제하려고 시도하지 마세요. 이것은 당신의 콘텐츠 아키텍처를 재생각하고 개선할 기회입니다. 다음을 감사하여 시작하세요:
- 어떤 콘텐츠 타입이 존재합니까? tt_content CTypes을 내보내고 모든 확장 레코드 타입을 나열합니다.
- 어떤 필드가 실제로 사용됩니까? TYPO3 테이블에는 수십 개의 필드가 있습니다. 대부분의 콘텐츠는 몇 개만 사용합니다.
- 관계는 무엇입니까? 콘텐츠가 다른 콘텐츠를 어떻게 참조하는지 매핑합니다.
- 번역 설정은 무엇입니까? TYPO3는 연결된 번역과 자유 번역 모드를 지원합니다 -- 헤드리스 CMS는 어느 것을 사용하든 처리해야 합니다.
-- 유용한 TYPO3 감사 쿼리
-- 타입별 콘텐츠 요소 계산
SELECT CType, COUNT(*) as count
FROM tt_content
WHERE deleted = 0 AND hidden = 0
GROUP BY CType
ORDER BY count DESC;
-- doktype별 페이지 계산
SELECT doktype, COUNT(*) as count
FROM pages
WHERE deleted = 0 AND hidden = 0
GROUP BY doktype
ORDER BY count DESC;
-- 사용 중인 모든 언어 찾기
SELECT sys_language_uid, COUNT(*) as count
FROM tt_content
WHERE deleted = 0
GROUP BY sys_language_uid;
데이터 마이그레이션 전략
대상 CMS에서 콘텐츠 모델을 정의한 후에는 실제로 데이터를 이동해야 합니다. 세 가지 주요 접근 방식이 있습니다.
방식 1: 스크립트 기반 내보내기/가져오기
TYPO3의 데이터베이스를 직접 쿼리하고, 데이터를 변환하고, 헤드리스 CMS의 관리 API를 통해 푸시하는 스크립트를 작성합니다. 이것이 가장 일반적인 접근 방식이며 가장 많은 제어를 제공합니다.
// 예제: TYPO3 news 레코드를 Contentful로 마이그레이션
const contentful = require('contentful-management');
const mysql = require('mysql2/promise');
async function migrateNews() {
const db = await mysql.createConnection({
host: 'localhost',
database: 'typo3_db',
user: 'root',
password: 'password'
});
const client = contentful.createClient({
accessToken: 'your-management-token'
});
const space = await client.getSpace('your-space-id');
const env = await space.getEnvironment('master');
const [rows] = await db.execute(`
SELECT n.uid, n.title, n.teaser, n.bodytext, n.datetime,
n.path_segment, p.slug as category_slug
FROM tx_news_domain_model_news n
LEFT JOIN sys_category_record_mm mm ON mm.uid_foreign = n.uid
LEFT JOIN sys_category c ON c.uid = mm.uid_local
WHERE n.deleted = 0 AND n.hidden = 0
`);
for (const row of rows) {
const entry = await env.createEntry('article', {
fields: {
title: { 'en-US': row.title },
teaser: { 'en-US': row.teaser },
body: { 'en-US': convertRteToRichText(row.bodytext) },
publishDate: { 'en-US': new Date(row.datetime * 1000).toISOString() },
slug: { 'en-US': row.path_segment }
}
});
await entry.publish();
console.log(`마이그레이션됨: ${row.title}`);
}
}
convertRteToRichText 함수는 상황이 복잡해지는 지점입니다. TYPO3의 RTE 출력은 HTML입니다(<link> 태그 같은 내부 링크용 사용자 정의 태그가 포함되는 경우가 많습니다). 이를 구조화된 rich text 형식으로 변환하는 것은 CMS에 따라 다릅니다 -- Contentful은 자신의 rich text JSON을 사용하고, Sanity는 Portable Text를 사용합니다 등등입니다.
방식 2: TYPO3 Headless 확장을 브리지로 사용
기존 TYPO3 인스턴스에 EXT:headless 확장을 설치합니다. 이것은 TYPO3를 JSON API로 변환하여, 마이그레이션 스크립트에서 소비하거나 새 프론트엔드가 구축되는 동안 임시로 헤드리스 백엔드로 사용할 수 있습니다.
이 접근 방식의 좋은 점은: 먼저 새 프론트엔드를 TYPO3의 headless API에 대해 실행한 다음, 나중에 백엔드를 적절한 헤드리스 CMS로 전환할 수 있습니다. 마이그레이션을 두 가지 단계로 나눕니다.
방식 3: 수동 재생성
더 작은 사이트(100개 페이지 미만)의 경우, 때로는 새 CMS에서 콘텐츠를 수동으로 재생성하는 것이 더 빠릅니다. 특히 콘텐츠를 재구성하고 다시 쓰는 경우 -- 아마도 어차피 해야 할 일입니다.
프론트엔드 아키텍처 결정
헤드리스 CMS를 사용하면 별도의 프론트엔드가 필요합니다. 실제 성능 향상이 일어나는 곳입니다.
Next.js
가장 인기 있는 선택입니다. 서버 측 렌더링, 정적 생성, 증분 정적 재생성 -- Next.js는 당신이 필요할 수 있는 모든 렌더링 전략을 처리합니다. App Router(Next.js 13.4부터 안정적)가 React Server Components와 함께 콘텐츠가 풍부한 사이트에 특히 잘 맞습니다. 우리는 우리의 Next.js 개발 전문을 통해 많은 이 작업을 합니다.
Astro
콘텐츠가 풍부하고 많은 상호작용이 필요하지 않은 사이트의 경우, Astro는 놀랍습니다. 기본적으로 JavaScript를 전혀 제공하지 않으며 Islands Architecture를 통한 부분 수화를 지원합니다. 우리는 Astro 빌드로 Lighthouse 점수가 일관되게 95+에 도달하는 것을 봤으며, 이는 일반적인 TYPO3 프론트엔드 성능 대비 급격한 개선입니다. 이것에 관심이 있으면 우리의 Astro 개발 서비스를 확인하세요.
Nuxt
당신의 팀이 React보다 Vue를 선호하는 경우, Nuxt 3은 Next.js와 동등합니다. 견고한 선택, 좋은 DX, 좋은 생태계입니다.
| 프레임워크 | 최적 사용 | 제공된 JS | 학습 곡선 | CMS 통합 |
|---|---|---|---|---|
| Next.js | 동적 앱, 전자상거래, 대시보드 | 중간-높음 | 중간 | 우수 |
| Astro | 콘텐츠 사이트, 블로그, 마케팅 | 최소 | 낮음 | 우수 |
| Nuxt 3 | Vue 팀, 콘텐츠 + 앱 | 중간 | 중간 | 좋음 |
| SvelteKit | 작은 팀, 단순함 추구 | 낮음 | 낮음-중간 | 성장 중 |
TYPO3 고유 기능 처리
일부 TYPO3 기능은 헤드리스 세계에서 직접 동등합니다. 일반적인 기능들을 처리하는 방법은 다음과 같습니다.
작업 공간 및 버전 관리
TYPO3의 작업 공간 시스템을 통해 편집자는 게시하기 전에 여러 페이지에 걸쳐 변경 사항을 준비할 수 있습니다. 대부분의 헤드리스 CMS 플랫폼은 이를 부분적으로 복제하는 환경 또는 릴리즈 스케줄링을 제공합니다. Contentful에는 Environments와 Scheduled Publishing이 있습니다. Sanity에는 Releases가 있습니다(최근 출시). 어느 것도 기본적으로 TYPO3 Workspaces만큼 정교하지는 않으므로, 편집자가 작업 공간에 크게 의존하는 경우 워크플로우 조정을 계획하세요.
백엔드 사용자 권한
TYPO3의 권한 시스템은 매우 세분화되어 있습니다 -- 페이지 수준, 콘텐츠 요소 수준, 필드 수준 접근 제어입니다. 헤드리스 CMS 플랫폼은 여기서 광범위하게 다릅니다. Contentful의 역할 시스템은 괜찮지만 덜 세분화되어 있습니다. Sanity의 것은 더 유연하지만 맞춤 구성이 필요합니다. Strapi의 역할 기반 접근은 좋습니다. 약속하기 전에 현재 권한 매트릭스를 감사하고 대상 CMS가 이를 처리할 수 있는지 확인하세요.
폼 처리
TYPO3의 Form Framework(EXT:form)는 YAML 구성에서 폼을 생성합니다. 헤드리스 설정에서는 폼 서비스가 필요합니다. 옵션에는 Formspree, Basin, 또는 서버리스 함수로 자체 빌드가 포함됩니다. Next.js를 사용하는 경우, Server Actions은 폼 처리를 간단하게 만듭니다.
다국어 및 지역화
이것은 중요하며 종종 과소평가됩니다. TYPO3의 번역 처리 -- 언어 오버레이의 개념, 연결된/자유 모드, 그리고 폴백 체인 -- 정교합니다. 대상 CMS를 선택하기 전에 정확한 번역 요구사항을 매핑하세요. Storyblok과 Contentful은 지역 관리를 잘 처리합니다. Sanity는 복잡한 다국어 시나리오에 더 많은 맞춤 설정이 필요합니다.
마이그레이션 중 SEO 보존
이 섹션은 가장 중요할 수 있습니다. 엉망으로 진행된 마이그레이션은 유기 트래픽을 무너뜨릴 수 있습니다.
URL 매핑
TYPO3 사이트의 모든 URL을 내보냅니다. 모든. 단 하나도 빼지 말고. Screaming Frog 또는 wget --spider 같은 크롤러를 사용하여 완전한 URL 목록을 작성합니다. 그런 다음 리디렉션 맵을 생성하세요:
/old-typo3-path/page.html → /new-clean-path
/index.php?id=42 → /about-us
/fileadmin/documents/report.pdf → /assets/report.pdf
변경되는 모든 URL에 대해 301 리디렉션을 구현합니다. Next.js에서는 next.config.js로 이동합니다:
// next.config.js
module.exports = {
async redirects() {
return [
{
source: '/old-path/:slug*',
destination: '/new-path/:slug*',
permanent: true,
},
// ... 수백 개 더, 이상적으로 JSON 파일에서 로드됨
];
},
};
대규모 리디렉션 목록(500+)의 경우, 애플리케이션 구성보다는 에지에서 리디렉션 처리를 고려하세요(Vercel Edge Middleware, Cloudflare Workers, 또는 nginx).
메타 데이터 마이그레이션
TYPO3는 pages 테이블(seo_title, description, og_image 등)과 잠재적으로 EXT:cs_seo 또는 EXT:seo_basics 같은 확장에 SEO 메타데이터를 저장합니다. 이 모든 것을 추출하고 헤드리스 CMS 콘텐츠 모델로 마이그레이션합니다. 다음을 잊지 마세요:
- 페이지 제목 및 메타 설명
- Open Graph 및 Twitter Card 데이터
- 정규 URL
- 다국어 사이트에 대한 hreflang 태그
- 구조화된 데이터 / JSON-LD 스키마
- XML sitemap 생성
모니터링
마이그레이션 전에 Google Search Console을 새 도메인/서브도메인에 설정합니다. 런칭 후, 처음 2주 동안 매일 Coverage 보고서를 모니터링합니다. 크롤 오류, 누락된 페이지, 그리고 인덱싱 문제를 확인하세요. 롤백 계획을 세우세요.
테스트 및 런칭 전략
단계별 접근 방식보다는 대규모 전환을 권장합니다.
단계 1: 병렬 실행(2-4주)
staging 도메인에서 새 헤드리스 사이트를 실행합니다. TYPO3 사이트와의 콘텐츠 동등성을 비교합니다. 편집자가 콘텐츠 워크플로우를 테스트하게 합니다. Percy 또는 Playwright 같은 도구를 사용하여 자동화된 시각적 회귀 테스트를 실행합니다.
단계 2: 소프트 런칭
CDN 수준의 기능 플래그 또는 A/B 테스트를 사용하여 트래픽의 작은 백분율을 새 사이트로 라우팅합니다. Core Web Vitals, 오류율, 그리고 사용자 행동을 모니터링합니다.
단계 3: 전체 전환
DNS 또는 역방향 프록시 구성을 전환합니다. 모든 리디렉션을 활성화합니다. 48시간 동안 적극적으로 모니터링합니다. TYPO3 인스턴스를 최소 30일 동안 실행 상태(읽기 전용)로 유지합니다.
단계 4: 폐지
마이그레이션이 안정적이라는 확신이 들면, TYPO3 인프라를 종료합니다. 데이터베이스와 fileadmin 디렉토리를 보관합니다. 나중에 누군가 오래된 콘텐츠에 대해 질문할 때 당신에게 감사합니다.
실제 마이그레이션 타임라인 및 비용
솔직하게 말합시다. 이것이 무엇을 비용하는지. 너무 많은 팀이 마이그레이션 프로젝트를 과소평가했습니다.
| 프로젝트 크기 | 페이지 | 타임라인 | 예상 비용 |
|---|---|---|---|
| 소형 | 50-200 | 6-10주 | $15,000-$35,000 |
| 중형 | 200-1,000 | 12-20주 | $40,000-$90,000 |
| 대형 | 1,000-5,000 | 20-36주 | $80,000-$200,000 |
| 엔터프라이즈 | 5,000+ | 6-12개월 | $150,000-$500,000+ |
이 숫자는 콘텐츠 모델링, 마이그레이션 스크립팅, 프론트엔드 개발, 테스트, 그리고 런칭 지원을 포함합니다. CMS 라이선싱 비용은 포함하지 않으며, 이는 플랫폼에 따라 다릅니다.
가장 큰 비용 드라이버는:
- 콘텐츠 타입의 수 및 복잡성 -- 원시 페이지 수가 아님
- 새 동등 기능이 필요한 사용자 정의 TYPO3 확장
- 다국어 설정 복잡성
- 통합 요구사항(검색, 전자상거래, 인증)
- 편집자 교육 및 변화 관리
당신의 특정 설정에 대해 마이그레이션이 어떻게 보일 수 있는지 논의하고 싶으면, 우리에게 연락하거나 참여 모델을 위해 가격 페이지를 확인하세요.
FAQ
TYPO3를 새로운 마이그레이션 대신 헤드리스 CMS로 사용할 수 있습니까?
예, EXT:headless 확장(이전의 "headless")은 TYPO3를 JSON API로 변환합니다. 이것은 좋은 중간 단계가 될 수 있습니다. 하지만 당신은 여전히 모든 운영 오버헤드가 있는 TYPO3 백엔드를 유지해야 합니다. TYPO3 종속성 감소가 당신의 목표라면 브리지 전략으로 의미가 있지만 일반적으로 장기 답변이 아닙니다.
일반적인 TYPO3에서 헤드리스 CMS 마이그레이션은 얼마나 걸립니까?
중간 크기의 사이트(200-1,000개 페이지)의 경우, 킥오프부터 런칭까지 3-5개월 예상하세요. 콘텐츠 모델링 및 마이그레이션 스크립팅 단계는 일반적으로 팀이 예상하는 것보다 오래 걸립니다. 프론트엔드 개발은 콘텐츠 모델이 정의되면 종종 병렬로 실행될 수 있습니다. 다중 언어와 복잡한 통합이 있는 엔터프라이즈 마이그레이션은 6-12개월이 걸릴 수 있습니다.
마이그레이션 중에 SEO 순위를 잃게 됩니까?
올바르게 수행하면 그렇지 않아야 합니다. 중요한 요인은: 변경된 모든 URL에 대해 적절한 301 리디렉션 구현, 모든 메타 데이터 마이그레이션, 사이트 구조 및 내부 링크 유지, 그리고 Google에 업데이트된 사이트맵 제출입니다. 마이그레이션 후 2-4주 동안 순위의 일시적 하락은 정상이며 일반적으로 복구됩니다. 영구적 손실은 일반적으로 누락된 리디렉션 또는 손실된 콘텐츠를 나타냅니다.
TYPO3를 대체하기 위한 최고의 헤드리스 CMS는 무엇입니까?
당신의 우선순위에 따라 다릅니다. Storyblok은 종종 TYPO3 편집자에게 가장 부드러운 전환입니다. 시각적 편집 기능 때문입니다. Contentful은 가장 성숙한 생태계를 가진 가장 안전한 엔터프라이즈 선택입니다. Sanity는 가장 많은 개발자 유연성을 제공합니다. Strapi는 자체 호스팅이 필요한 경우 최고의 오픈소스 옵션입니다. 단일 최고의 답변이 없습니다 -- 당신의 팀, 예산, 그리고 요구사항에 따라 다릅니다.
TYPO3 확장은 마이그레이션 후 어떻게 됩니까?
각 확장을 개별적으로 평가해야 합니다. EXT:news, EXT:cal, 그리고 EXT:powermail 같은 일반적인 확장은 새 스택에서 동등한 기능이 필요합니다. News/blog 기능은 모든 헤드리스 CMS로 복제하기가 간단합니다. 일정 및 이벤트 기능은 제3자 서비스가 필요할 수 있습니다. 폼은 새 솔루션(폼 빌더, 서버리스 함수, 또는 Formspree 같은 서비스)이 필요합니다. 사용자 정의 확장은 가장 많은 분석이 필요합니다.
마이그레이션 중 TYPO3의 fileadmin 자산을 어떻게 처리합니까?
모든 자산(이미지, PDF, 비디오)을 새 CMS의 자산 관리 시스템 또는 별도의 DAM/CDN으로 마이그레이션해야 합니다. fileadmin에서 다운로드하고, 새 플랫폼의 API를 통해 업로드하고, 이전 파일 참조를 새 자산 ID에 매핑하는 스크립트를 작성합니다. 처리된/크기 조정된 이미지를 잊지 마세요 -- 대부분의 헤드리스 CMS 플랫폼은 이미지 변환을 자동으로 처리하므로 일반적으로 원본만 마이그레이션하면 됩니다.
증분 방식으로 마이그레이션할 수 있습니까 아니면 한번에 모두 해야 합니까?
증분 마이그레이션은 가능하며 때로는 대규모 사이트에 권장됩니다. 역방향 프록시를 사용하여 특정 URL 경로를 새 헤드리스 프론트엔드로 라우팅하고 다른 경로는 TYPO3에 유지할 수 있습니다. 이것은 섹션별로 마이그레이션할 수 있게 합니다. 트레이드오프는 두 시스템을 동시에 관리하는 증가된 복잡성 및 두 시스템 모두에서 일관된 네비게이션과 디자인을 유지하는 것입니다.
TYPO3 백엔드 사용자의 변경 저항에 대해 어떻게 해야 합니까?
변화 관리는 진정으로 전투의 절반입니다. 편집자를 조기에 포함시키세요 -- 모든 것이 구축된 후가 아닌 콘텐츠 모델링 단계 동안 새 CMS를 보여주세요. 좋은 편집 경험이 있는 CMS를 선택하세요(Storyblok과 Contentful은 일반적으로 편집자로부터 최고의 피드백을 받습니다). 당신의 설정에 특정한 문서 및 교육 자료를 만드세요. 그리고 무엇이 변하고 있는지, 그리고 왜 변하고 있는지에 대해 솔직하세요 -- 편집자는 일반적으로 개선된 미리보기 경험과 더 빠른 게시 워크플로우를 볼 때 동의합니다.