TYPO3 마이그레이션 체크리스트: 개발자 단계별 가이드
지난 몇 년간 충분한 TYPO3 마이그레이션을 경험하면서 나는 알게 되었다. 부드러운 전환과 6개월짜리 악몽의 차이는 준비에서 비롯된다는 것을. TYPO3는 강력한 CMS다 — 1998년부터 존재해왔고 특히 DACH 지역에서 매우 복잡한 엔터프라이즈 사이트들을 운영하고 있다. 하지만 TYPO3의 주요 버전 간에 업그레이드하든 완전히 다른 플랫폼으로 이동하든, 계획이 없으면 마이그레이션 프로세스는 빠르게 엉망이 될 수 있다.
이것은 내 첫 TYPO3 마이그레이션 전에 누군가가 내게 건넸으면 좋았을 체크리스트다. 이론적인 것이 아니다. 여기 있는 모든 항목은 당신이 그것을 건너뛰면 어떤 일이 일어나는지 내가 봤기 때문에 존재한다.
목차
- 현재 TYPO3 설치 평가하기
- 마이그레이션 전략 정의하기
- 콘텐츠 감사 및 데이터 매핑
- 기술 인프라 준비
- 확장 및 통합 인벤토리
- SEO 보존 계획
- 마이그레이션 실행 단계
- 테스팅 및 품질 보증
- 마이그레이션 후 모니터링
- 일반적인 TYPO3 마이그레이션 함정
- FAQ
현재 TYPO3 설치 평가하기
아무것도 건드리기 전에 정확히 무엇을 다루고 있는지 이해해야 한다. 당연해 보인다. 아니다. 프로덕션에서 실행 중인 TYPO3 버전이 무엇인지도 모르는 팀의 프로젝트에 들어가본 적이 있다.
버전 및 환경 감사
여기서 시작하자:
# TYPO3 버전 확인
php typo3/sysext/core/bin/typo3 --version
# 또는 백엔드를 통해 확인: Help > About TYPO3
다음을 문서화하자:
- TYPO3 버전 (주 버전과 부 버전 — 예: TYPO3 v11.5.38 LTS)
- 서버에서 실행 중인 PHP 버전
- 데이터베이스 유형 및 버전 (MySQL, MariaDB, PostgreSQL)
- 웹 서버 (Apache, Nginx)
- Composer 기반 또는 클래식 설치 — 이것은 매우 중요하다
- 설치의 사이트/도메인 수 (다중 사이트 설정은 복잡성을 추가한다)
- 페이지 트리의 총 페이지 및 콘텐츠 요소 수
사용자 및 권한 매핑
TYPO3의 백엔드 사용자 및 그룹 권한 시스템은 매우 세분화되어 있다. be_users 및 be_groups 테이블을 내보내고 다음을 문서화하자:
- 존재하는 백엔드 사용자의 수
- 구성된 사용자 지정 권한
- 관리자 액세스 권한이 있는 사용자
- 사용자 지정 TSconfig 오버라이드
다른 CMS로 마이그레이션하는 경우 이러한 역할을 새 시스템의 권한 모델에 매핑해야 한다. TYPO3 버전을 업그레이드하는 경우 일부 권한 구성을 업데이트해야 할 수 있다.
TypoScript 및 구성 복잡성
TypoScript 설정의 빠른 감사를 실행하자:
# TypoScript 파일 수 계산
find . -name '*.typoscript' -o -name '*.ts' | wc -l
# 레거시 형식의 setup.txt 및 constants.txt 확인
find . -name 'setup.txt' -o -name 'constants.txt' | wc -l
깊게 중첩된 구성을 가진 수백 개의 TypoScript 파일이 있다면 마이그레이션이 더 오래 걸릴 것으로 예상하자. 15년에 걸쳐 진화한 10,000줄 이상의 TypoScript를 가진 TYPO3 설치를 본 적이 있다. 그것은 주말 프로젝트가 아니다.
마이그레이션 전략 정의하기
기본적으로 세 가지 유형의 TYPO3 마이그레이션이 있고, 다른 무엇보다 먼저 어느 것을 하는지 결정해야 한다.
| 마이그레이션 유형 | 선택할 때 | 복잡성 | 일반적인 타임라인 |
|---|---|---|---|
| TYPO3 버전 업그레이드 (예: v10 → v12) | TYPO3를 계속 사용하고 싶을 때 | 중간-높음 | 4-12주 |
| TYPO3에서 헤드리스 CMS로 (예: Contentful, Strapi, Sanity) | 현대적인 프론트엔드 유연성을 원할 때 | 높음 | 8-20주 |
| TYPO3에서 다른 전통적인 CMS로 (예: WordPress, Drupal) | 다른 모놀리식 CMS를 원할 때 | 중간 | 6-16주 |
| TYPO3에서 헤드리스 TYPO3로 (EXT:headless 사용) | TYPO3 백엔드와 현대적인 프론트엔드를 원할 때 | 중간 | 6-14주 |
TYPO3 내에서 업그레이드
TYPO3를 계속 사용하는 경우 공식 업그레이드 경로는 각 LTS 버전을 단계적으로 거쳐야 한다. v8에서 v12로 직접 점프할 수는 없다. 글쎄, 시도할 수 있다. 하지 마라.
2025년 현재 권장 경로:
- v8 LTS → v9 LTS → v10 LTS → v11 LTS → v12 LTS → v13 LTS
TYPO3 v13 LTS는 2024년 후반에 릴리스되었고 현재 장기 지원 버전이다. TYPO3 v12 LTS는 2026년 4월까지 확장 장기 지원(ELTS) 프로그램을 통해 보안 업데이트를 받을 것이다.
TYPO3에서 떠나기
헤드리스 아키텍처로 이동하는 경우 — 솔직히 많은 팀에게 이것은 말이 된다 — 프론트엔드 프레임워크 옵션을 평가해야 한다. 우리는 Next.js와 Astro를 헤드리스 CMS 플랫폼과 쌍으로 사용한 광범위한 작업을 했다.
핵심 질문은: 당신의 콘텐츠 모델이 TYPO3의 복잡성을 정당화하는가? 200개 페이지가 있는 마케팅 사이트를 운영 중이라면 TYPO3는 아마도 과도할 것이다. 복잡한 워크플로우가 있는 다중 언어 엔터프라이즈 포털을 운영 중이라면 마이그레이션 중 콘텐츠 모델링 작업은 어디로 가든지 중요할 것이다.
콘텐츠 감사 및 데이터 매핑
마이그레이션이 성공하거나 실패하는 곳은 여기다. 콘텐츠.
데이터베이스 내보내기 및 분석
TYPO3는 주로 다음 테이블에 콘텐츠를 저장한다:
pages— 페이지 트리 구조tt_content— 콘텐츠 요소sys_file및sys_file_reference— 미디어 자산 (FAL)sys_category— 카테고리tx_news_domain_model_news— news 확장을 사용하는 경우
콘텐츠를 내보내고 실제 숫자를 얻자:
-- 타입별로 페이지 계산
SELECT doktype, COUNT(*) as count
FROM pages
WHERE deleted = 0
GROUP BY doktype;
-- 타입별로 콘텐츠 요소 계산
SELECT CType, COUNT(*) as count
FROM tt_content
WHERE deleted = 0 AND hidden = 0
GROUP BY CType
ORDER BY count DESC;
-- 파일 참조 계산
SELECT COUNT(*) FROM sys_file WHERE missing = 0;
콘텐츠 타입 매핑
모든 TYPO3 콘텐츠 타입(CType)을 대상 시스템의 동등물로 매핑하는 스프레드시트를 만들자. 당신이 마주칠 일반적인 TYPO3 콘텐츠 타입:
text,textmedia,textpic— 표준 텍스트 콘텐츠image— 이미지 갤러리table— 데이터 테이블bullets— 목록uploads— 파일 목록html— 원본 HTML (마이그레이션 중 항상 재미있다)list— 플러그인 콘텐츠 (여기서 복잡해진다)- 확장에서의 사용자 지정 콘텐츠 타입
list CType은 까다로운 것이다. 플러그인 콘텐츠 — 뉴스 목록, 양식, 사용자 지정 기능 — 를 나타내고 각각은 개별적인 주의가 필요하다.
다중 언어 콘텐츠
TYPO3는 연결된 모드(번역이 기본 언어 레코드에 연결된 곳) 또는 자유 모드를 통해 번역을 처리한다. 당신의 사이트가 어느 접근방식을 사용하는지 확인하자:
-- 번역 설정 확인
SELECT sys_language_uid, COUNT(*)
FROM pages
WHERE deleted = 0
GROUP BY sys_language_uid;
연결된 모드 번역으로 8개 언어가 있다면 마이그레이션 데이터 매핑이 방금 8배 더 복잡해졌다. 그에 따라 계획하자.
기술 인프라 준비
서버 요구 사항
TYPO3 v13으로 업그레이드하는 경우 2025년 현재 최소 요구 사항:
- PHP 8.2 이상 (8.3 권장)
- MySQL 8.0+ 또는 MariaDB 10.4+ 또는 PostgreSQL 12+
- 256MB PHP 메모리 제한 최소 (512MB 권장)
- Composer 2.7+
스테이징 환경
절대로 — 이것을 충분히 강조할 수 없다 — 프로덕션에서 직접 마이그레이션을 실행하지 마라. 다음을 설정하자:
- 프로덕션을 미러링하는 스테이징 환경
- 별도의 데이터베이스 복사본
- 동일한 PHP 및 서버 구성
- 파일 스토리지 액세스 (또는 fileadmin의 복사본)
# 데이터베이스를 스테이징으로 복제
mysqldump -u root -p production_db | mysql -u root -p staging_db
# fileadmin Rsync
rsync -avz production:/var/www/html/fileadmin/ staging:/var/www/html/fileadmin/
백업 전략
마이그레이션 작업이 시작되기 전에:
- 타임스탬프를 가진 전체 데이터베이스 덤프
- fileadmin, typo3conf 및 모든 사용자 지정 확장 디렉토리를 포함한 완전한 파일 시스템 백업
- LocalConfiguration.php 및 AdditionalConfiguration.php 설정 문서화
- TypoScript 템플릿 내보내기
이러한 백업을 마이그레이션 환경과 완전히 분리된 곳에 보관하자. 나는 최소 3개의 복사본을 유지한다.
확장 및 통합 인벤토리
TYPO3 확장은 아마도 마이그레이션 문제의 가장 큰 원인일 것이다. 이를 처리하는 방법은 다음과 같다.
설치된 모든 확장 나열
# Composer 기반 설치
composer show | grep typo3
# 또는 PackageStates.php 확인
cat typo3conf/PackageStates.php
각 확장 분류
모든 확장에 대해 다음을 결정하자:
| 범주 | 필요한 조치 | 예시 |
|---|---|---|
| 핵심 시스템 확장 | 일반적으로 업그레이드 마법사로 처리 | fluid_styled_content, form |
| 유지되는 TER 확장 | 대상 버전과의 호환성 확인 | news, powermail, solr |
| 중단된 TER 확장 | 대체 또는 사용자 지정 솔루션 찾기 | 다양함 |
| 사용자 지정 사이트 확장 | 수동 마이그레이션/재작성 필요 | 당신의 site_package |
| 상용 확장 | 공급업체에 마이그레이션 경로 문의 | in2publish, 다양함 |
일반적인 확장 마이그레이션 경로
거의 모든 TYPO3 마이그레이션에서 보는 확장:
- EXT:news (Georg Ringer) — 버전 호환성 확인; v11+은 TYPO3 v12/v13과 작동
- EXT:powermail — 인기 있는 양식 확장; 대체는 EXT:form (핵심) 포함
- EXT:realurl — TYPO3 v9 이후 더 이상 사용되지 않음; 코어 라우팅으로 대체됨
- EXT:tt_address — 일반적으로 간단한 업그레이드
- EXT:gridelements 또는 EXT:flux — 이러한 레이아웃 확장은 업그레이드 중 가장 많은 문제를 일으킨다. TYPO3에서 떠나가는 경우 그리드 구조에서 콘텐츠를 추출하는 상당한 작업을 예상하자.
SEO 보존 계획
이 섹션을 건너뛰면 회사가 유기 트래픽에서 수백만 달러의 손실을 입을 수 있다. 그런 팀이 되지 마라.
URL 매핑
- Screaming Frog, Sitebulb 또는 Ahrefs를 사용하여 전체 현재 사이트를 크롤링
- 모든 URL 내보내기 (큰 TYPO3 사이트의 경우 수천 개를 예상)
- 완전한 1:1 URL 매핑 문서 생성
- 유기 트래픽별 상위 100개 페이지 확인 (Google Search Console 확인)
- 높은 트래픽 페이지에 대한 리디렉션 정확성 우선 순위
리디렉션 구현
# .htaccess 리디렉션 예시
RedirectPermanent /old-typo3-path/page.html /new-path/page
RedirectPermanent /index.php?id=123 /about-us
대규모 리디렉션의 경우 .htaccess에 수천 개의 규칙을 넣는 대신 리디렉션 관리 솔루션을 사용하자. 현대적인 스택으로 이동하는 경우 대부분의 프레임워크 및 호스팅 플랫폼 (Vercel, Netlify)은 리디렉션 구성 파일을 가지고 있다.
메타 데이터 마이그레이션
TYPO3는 v9에서 EXT:seo가 핵심 확장이 된 이후로 pages 테이블에 SEO 메타데이터를 저장한다:
seo_titleog_title,og_description,og_imagetwitter_title,twitter_description,twitter_imagecanonical_linkno_index,no_follow
이 모든 것을 내보내고 매핑해야 한다. 500개 페이지 전체에서 메타 설명을 잃어버리는 것은 예방 가능한 재앙이다.
마이그레이션 실행 단계
TYPO3 버전 업그레이드의 경우
각 버전 단계에 대해 이 시퀀스를 따르자:
- Composer 의존성 업데이트 다음 LTS 버전으로
- 업그레이드 마법사 실행 Install Tool에서 (Admin Tools > Upgrade)
- 데이터베이스 분석기 실행 스키마를 업데이트
- 저절증 로그 확인 문제
- 확장 업데이트 호환되는 버전으로
- TypoScript 수정 저절증 및 주요 변경 사항
- 철저히 테스트 다음 버전 단계로 이동하기 전에
# Composer를 통해 TYPO3 코어 업데이트
composer require typo3/cms-core:^13.4 typo3/cms-backend:^13.4 \
typo3/cms-frontend:^13.4 --with-all-dependencies
# CLI를 통해 업그레이드 마법사 실행
php typo3/sysext/core/bin/typo3 upgrade:run
# 데이터베이스 스키마 업데이트
php typo3/sysext/core/bin/typo3 database:updateschema
플랫폼 마이그레이션의 경우
헤드리스 CMS 아키텍처로 마이그레이션하는 경우 실행 단계는 다르게 보인다:
- 새로운 CMS 설정 및 콘텐츠 모델 구성
- 마이그레이션 스크립트 구축 TYPO3 데이터를 변환하기 위해
- 배치로 콘텐츠 마이그레이션 — 가장 간단한 콘텐츠 타입으로 시작
- 미디어 자산 처리 — fileadmin에서 다운로드하고 새 자산 스토리지에 업로드
- 프론트엔드 구축 선택한 프레임워크 사용
- 리디렉션 구현 go-live 전에
- DNS 전환 및 모니터링
실제 데이터 변환의 경우 일반적으로 TYPO3 데이터베이스에서 읽고 새로운 CMS API를 통해 콘텐츠를 푸시하는 Python 또는 Node.js 스크립트를 작성한다:
import mysql.connector
import requests
# TYPO3 데이터베이스에 연결
db = mysql.connector.connect(
host="localhost",
user="typo3",
password="password",
database="typo3_db"
)
cursor = db.cursor(dictionary=True)
cursor.execute("""
SELECT uid, title, description, slug,
seo_title, og_description
FROM pages
WHERE deleted = 0 AND hidden = 0
AND sys_language_uid = 0
ORDER BY sorting
""")
for page in cursor.fetchall():
# 변환하고 새로운 CMS로 푸시
payload = {
"title": page["title"],
"slug": page["slug"],
"seoTitle": page["seo_title"] or page["title"],
"description": page["og_description"] or page["description"]
}
# 새로운 CMS API로 POST
response = requests.post(
"https://api.new-cms.com/content",
json=payload,
headers={"Authorization": "Bearer YOUR_TOKEN"}
)
print(f"Migrated page {page['uid']}: {response.status_code}")
테스팅 및 품질 보증
자동화된 테스팅 체크리스트
- 모든 페이지가 200 상태 코드 반환
- 깨진 내부 링크 없음
- 모든 이미지가 제대로 로드됨
- 양식이 성공적으로 제출됨
- 검색 기능이 작동함
- 다중 언어 전환이 작동함
- 이전 URL에서의 리디렉션이 작동함
- 정규 URL이 정확함
- XML 사이트맵이 유효하고 접근 가능함
- robots.txt가 적절히 구성됨
- SSL 인증서가 유효함
- 페이지 로드 시간이 수용 가능함 (3초 미만)
시각적 회귀 테스팅
Percy, BackstopJS 또는 Playwright를 사용하여 시각적 비교:
# BackstopJS 예시
npx backstop init
# backstop.json에서 시나리오 구성
npx backstop reference # 현재 사이트 캡처
npx backstop test # 마이그레이션 후 비교
성능 벤치마크
마이그레이션 전후로 측정하자. 마이그레이션은 이상적으로 성능을 개선해야지 저하시키면 안 된다.
| 메트릭 | 마이그레이션 전 대상 | 마이그레이션 후 대상 |
|---|---|---|
| TTFB | < 800ms | < 200ms |
| LCP | < 2.5s | < 1.5s |
| CLS | < 0.1 | < 0.05 |
| FID/INP | < 200ms | < 100ms |
| PageSpeed Score | 50-70 | 90+ |
서버 렌더링 TYPO3에서 정적 또는 엣지 렌더링 프론트엔드로 이동하는 경우 이러한 숫자에서 극적인 개선을 볼 수 있어야 한다.
마이그레이션 후 모니터링
DNS를 전환할 때 마이그레이션이 끝나지 않는다. 최소 30일 동안 이를 모니터링하자:
- Google Search Console — 크롤링 오류, 커버리지 문제 및 인덱싱 문제를 관찰. 처음 2주에는 약간의 변동을 예상.
- 분석 — 마이그레이션 전 기준선과의 주대주 트래픽 패턴 비교.
- 404 오류 — 404에 대한 로깅을 설정하고 누락된 URL에 대한 리디렉션 추가.
- Core Web Vitals — CrUX 또는 분석 플랫폼을 통해 실제 사용자 데이터 모니터링.
- 서버 로그 — 비정상적인 오류 패턴을 관찰.
상위 50개 페이지에 있던 페이지의 트래픽이 20%를 초과하는 경우를 위한 경보를 설정하자.
일반적인 TYPO3 마이그레이션 함정
이들은 나는 실수했지만 수십 개의 마이그레이션 전체에서 본 실수들이다:
1. 소프트 삭제 레코드 무시하기. TYPO3는 실제로 레코드를 제거하는 대신 deleted=1 플래그를 사용한다. 마이그레이션 스크립트는 이를 필터링해야 하거나 수년 전에 삭제된 수천 개의 레코드를 임포트하게 된다.
2. 워크스페이스 잊기. 사이트가 편집 워크플로우를 위해 TYPO3 워크스페이스를 사용하는 경우 초안 콘텐츠가 내보내기에 섞여 있을 수 있다. 항상 t3ver_wsid = 0으로 필터링하여 라이브 콘텐츠만 얻자.
3. RTE 콘텐츠 과소평가하기. TYPO3의 rich text 편집기 출력은 사용자 지정 태그, <link> 태그와 TYPO3 특정 구문, t3:// URI를 포함할 수 있다. 이 모든 것을 파싱하고 변환해야 한다.
4. 파일 참조 깨뜨리기. TYPO3의 파일 추상화 레이어(FAL)는 sys_file_reference를 사용하여 파일을 콘텐츠에 연결한다. 간단한 "콘텐츠 레코드의 이미지 필드"가 아니다 — 관계 테이블이다. 마이그레이션 스크립트는 이러한 참조를 따라야 한다.
5. 실제 콘텐츠 볼륨으로 테스트하지 않기. 마이그레이션 스크립트는 10개의 테스트 페이지로 완벽하게 작동한다. 15,000개 페이지 및 50,000개 콘텐츠 요소로는 비극적으로 실패한다. 항상 규모에 따라 테스트하자.
TYPO3 마이그레이션을 계획 중이고 이러한 함정을 피하고 싶다면 여러 엔터프라이즈 팀을 TYPO3 마이그레이션을 통해 안내했다 — 자유롭게 연락 해서 당신의 특정 상황에 대해 이야기할 수 있다.
FAQ
TYPO3 마이그레이션은 일반적으로 얼마나 걸리나? 설치의 복잡성에 크게 달려 있다. 단일 언어 사이트의 표준 확장을 가진 간단한 TYPO3 v11에서 v13 업그레이드는 4-6주가 걸릴 수 있다. 사용자 지정 확장을 가진 다중 언어 엔터프라이즈 TYPO3 사이트의 완전한 플랫폼 마이그레이션은 쉽게 3-6개월이 걸릴 수 있다. 콘텐츠 감사 단계만 해도 큰 사이트의 경우 2-4주가 걸릴 수 있다.
TYPO3 버전 업그레이드 중 LTS 버전을 건너뛸 수 있나? 기술적으로는 안 되어야 한다. 공식 권장 사항은 각 LTS 버전을 순차적으로 업그레이드하는 것이다 (v8 → v9 → v10 → v11 → v12 → v13) 왜냐하면 각 버전에는 그 특정 단계에 대한 데이터 마이그레이션을 처리하는 업그레이드 마법사가 포함되기 때문이다. 버전을 건너뛰면 그 데이터 마이그레이션이 실행되지 않고 손상되었거나 고아 데이터로 끝나게 된다. 일부 에이전시는 건너뛰기-버전 업그레이드를 할 수 있다고 주장하지만 나는 몇 개월 후에 나타나는 미묘한 데이터 문제를 봤다.
TYPO3에서 WordPress로 마이그레이션해야 하나? 필요에 따라 달라진다. WordPress는 간단한 마케팅 사이트를 잘 처리하지만 복잡한 다중 언어 요구 사항, 세분화된 권한 또는 엔터프라이즈 워크플로우 때문에 원래 TYPO3를 선택했다면 WordPress는 걸음 뒤로 물러날 수 있다. 현대적인 프론트엔드 프레임워크와 쌍을 이룬 헤드리스 CMS가 TYPO3 엔터프라이즈 CMS 플랫폼을 떠나는 팀에 더 나은 적합일 수 있다는 것을 고려하자. 우리는 헤드리스 CMS 개발 접근 방식에 대해 썼다.
TYPO3 마이그레이션 중 내 SEO 순위에 어떤 일이 일어나나? 완벽한 리디렉션으로도 2-6주 동안 약간의 순위 변동을 예상하자. Google는 콘텐츠를 다시 크롤링하고 다시 인덱싱할 시간이 필요하다. 영향을 최소화하려면: 모든 URL에 대해 301 리디렉션을 구현하고 콘텐츠 구조를 원본만큼 가깝게 유지하고 즉시 업데이트된 사이트맵을 제출하고 Google Search Console에서 주소 변경 도구를 사용하자 (도메인을 변경하는 경우). 리디렉션을 제대로 처리한 사이트는 일반적으로 4-8주 내에 복구된다.
TYPO3 확장이 대상 플랫폼에 존재하지 않으면 어떻게 하나? 먼저 확장이 실제로 무엇을 하는지 결정하자. 많은 TYPO3 확장은 현대 플랫폼에 내장된 기능(양식 빌더, SEO 도구 또는 리디렉션 관리)을 제공한다. 사용자 지정 기능의 경우 동등한 플러그인/서비스를 찾거나 사용자 지정 기능을 구축해야 한다. 각 확장, 그 목적 및 대체 전략을 나열하는 스프레드시트를 만들자.
헤드리스 TYPO3로 완전히 마이그레이션하는 대신 이동하는 것이 가치가 있나? TYPO3 헤드리스 확장 (EXT:headless)은 팀이 TYPO3 백엔드에 만족하지만 현대적인 프론트엔드를 원하는 경우 합법적인 옵션이다. TYPO3 콘텐츠를 JSON API로 노출하여 Next.js, Nuxt 또는 Astro로 프론트엔드를 구축할 수 있다. 이 접근방식은 기존 콘텐츠 구조와 편집 워크플로우를 보존하면서 프레젠테이션 계층을 현대화한다. 좋은 중간 지점이지만 TYPO3 백엔드를 유지해야 한다는 것을 의미한다.
2025년 TYPO3 마이그레이션 비용은 얼마인가? 대략적인 수치: 중간 규모 사이트의 TYPO3 버전 업그레이드는 $15,000-$50,000 범위다. 헤드리스 아키텍처로의 완전한 플랫폼 마이그레이션은 콘텐츠 볼륨, 언어 수, 사용자 지정 기능 및 통합 복잡성에 따라 $40,000-$150,000+ 범위다. 이들은 작은 숫자가 아니지만 오래된 안전하지 않은 CMS 설치를 유지하는 비용과 비교하자. 프로젝트를 구성하는 방법에 대한 더 자세한 내용은 가격 페이지를 확인할 수 있다.
템플릿을 처음부터 다시 구축해야 하나? TYPO3 버전 업그레이드의 경우 일반적으로 완전히는 아니지만 — 저절증 ViewHelper를 처리하고 새로운 API를 위해 Fluid 템플릿을 업데이트해야 할 것이다. 플랫폼 마이그레이션의 경우 네, 새로운 프론트엔드를 구축하고 있다. 좋은 소식은 Next.js 및 Astro 같은 현대적인 프레임워크를 사용하면 Fluid/TypoScript 시대보다 성능 있는 프론트엔드를 훨씬 빠르게 구축할 수 있다는 것이다. 디자인은 같을 수 있다; 구현만 변한다.