TYPO3 마이그레이션 에이전시: TYPO3에서 성공적으로 이전하는 방법
이 문서를 읽고 있다면, TYPO3에서 막혔을 가능성이 높습니다. 어쩌면 당신의 에이전시가 TYPO3 v8에서 v12로의 업그레이드가 전체 재구축만큼 비용이 들 것이라고 말했을 수도 있습니다. 아니면 더 이상 TYPO3로 일하고 싶어하는 개발자를 찾을 수 없다는 것을 깨달았을 수도 있습니다. 또는 경쟁사들이 지난 분기에 새로운 기능 3개를 출시했는데 당신은 여전히 TYPO3 확장 업데이트를 기다리고 있다는 것을 깨달았을 수도 있습니다.
당신 혼자만이 아닙니다. TYPO3는 20년 이상 유럽의 엔터프라이즈 시장을 잘 지원했지만, 웹 산업은 계속 나아갔습니다. 그리고 올바른 마이그레이션 에이전시를 찾는 것 -- 당신이 어디에서 왔는지와 어디로 가야 하는지를 실제로 이해하는 에이전시 -- 은 원활한 전환과 6개월 악몽 사이의 차이입니다.
나는 충분히 많은 TYPO3 마이그레이션에 관여해 왔고, 무엇이 잘못되고 무엇이 올바른지 알고 있습니다. 모든 것을 함께 살펴보겠습니다.
목차
- TYPO3에서 마이그레이션하는 이유
- TYPO3 마이그레이션 에이전시가 실제로 하는 일
- TYPO3에서의 일반적인 마이그레이션 경로
- 아무도 경고하지 않는 기술적 문제
- TYPO3 마이그레이션 에이전시 평가 방법
- 마이그레이션 타임라인 및 비용 예상
- 마이그레이션 중 SEO 보존
- 사례 연구: 실제 마이그레이션의 모습
- FAQ
TYPO3에서 마이그레이션하는 이유
솔직하게 말하겠습니다: TYPO3는 죽지 않았습니다. v13 LTS는 2024년 말에 출시되었으며 실질적인 개선 사항이 있습니다. 하지만 조직이 증가하는 속도로 떠나가는 실제적이고 현실적인 이유들이 있습니다.
개발자 부족이 실제입니다
TYPO3의 시장 점유율은 수년 동안 감소해 왔습니다. 2025년 현재, W3Techs는 TYPO3를 알려진 CMS를 사용하는 모든 웹사이트의 약 0.4%에 배치하고 있으며, 이는 최고점인 약 1.2%에서 떨어진 것입니다. 이는 직접적으로 생태계에 진입하는 개발자 수의 감소로 이어집니다. LinkedIn에 TYPO3 개발자 역할을 게시해 보세요 -- WordPress, Next.js 또는 Drupal 역할과 비교하면 지원자 수가 훨씬 적을 것입니다.
TYPO3를 아는 개발자들은 나이가 들고 있거나 다른 기술 스택으로 이동했습니다. 2025년 DACH 지역의 경험 많은 TYPO3 개발자의 시간당 요금은 €120-180/시간이며, 동등한 Next.js 또는 Headless CMS 개발자의 경우 €80-120입니다.
TypoScript 및 Fluid 템플릿 피로
React나 일반적인 HTML에 사용한 프런트엔드 개발자에게 TypoScript를 설명하려고 한 번 시도해 본 적이 있다면, 당신은 그 고통을 알 것입니다. 이는 프로그래밍 언어처럼 작동하는 구성 언어이지만 정확히 둘 중 하나는 아닙니다. Fluid 템플릿은 더 합리적이지만, 전체 개발자 경험은 여전히 2010년에 갇혀 있는 것처럼 느껴집니다.
성능 및 현대 아키텍처
TYPO3의 페이지 렌더링 모델은 서버 측입니다. 제대로 구성되어 있으면 잘 캐시되지만, Next.js나 Astro 같은 프레임워크에서 사용하는 정적 사이트 생성이나 ISR(Incremental Static Regeneration) 방식과 경쟁할 수 없습니다. Core Web Vitals은 2025년 SEO에 중요하며, TYPO3 사이트를 지속적으로 녹색 점수를 획득하도록 하려면 상당한 최적화 작업이 필요합니다.
총 소유 비용
이것은 일반적으로 마이그레이션 대화를 촉발하는 것입니다. 호스팅(TYPO3는 PHP + MySQL/MariaDB + 적절한 서버 리소스가 필요함), 개발자 비용, 확장 라이선싱 및 유지보수 오버헤드를 고려하면, 중간 규모 조직의 경우 TYPO3의 TCO는 종종 현대 대안보다 연간 30-60% 초과합니다.
TYPO3 마이그레이션 에이전시가 실제로 하는 일
실제 마이그레이션 에이전시는 단순히 다른 플랫폼에서 웹사이트를 재구축하는 것이 아닙니다. 그것은 쉬운 부분입니다. 실제 작업이 어떻게 보이는지는 다음과 같습니다:
콘텐츠 감사 및 매핑
TYPO3는 자체 콘텐츠 요소 모델이 있는 관계형 데이터베이스에 콘텐츠를 저장합니다. 페이지, 콘텐츠 요소, 카테고리, 파일 참조, 인라인 관계 -- 모든 것이 깊게 상호 연결되어 있습니다. 마이그레이션 에이전시는 모든 콘텐츠 유형을 감사하고, 새 플랫폼의 콘텐츠 모델에 매핑하고, 재구조화가 필요한 것을 식별합니다.
이것만 해도 500+ 페이지가 있는 사이트의 경우 2-4주가 걸릴 수 있습니다.
데이터 추출 및 변환
TYPO3의 데이터베이스 스키마는 정확히 직관적이지 않습니다. tt_content, pages, sys_file_reference, sys_category 같은 테이블들은 모두 이해되고, 조인되고, 내보내야 합니다. 대부분의 에이전시는 콘텐츠를 꺼내 대상 플랫폼이 가져올 수 있는 형식으로 변환하는 사용자 정의 추출 스크립트를 구축합니다 -- 일반적으로 PHP나 Python으로.
URL 매핑 및 리디렉트 전략
TYPO3는 RealURL이나 내장 라우팅(v9 이후)을 사용하여 멋진 URL을 만듭니다. 모든 단일 URL은 새로운 동등물에 매핑되어야 하며, 301 리디렉트가 배치되어야 합니다. 이 단계를 놓치면 검색 순위가 하룻밤 사이에 망가집니다.
템플릿 및 컴포넌트 재구축
당신의 TYPO3 Fluid 템플릿과 TypoScript 구성은 대상 플랫폼이 사용하는 것으로 변환되어야 합니다 -- React 컴포넌트, Astro 컴포넌트, Twig 템플릿, 무엇이든. 이것이 실제 프런트엔드 재구축이 일어나는 곳입니다.
통합 마이그레이션
양식, 검색, 전자상거래, 뉴스레터, DAM(Digital Asset Management) 및 인증을 위한 TYPO3 확장은 모두 새 플랫폼에서 동등한 솔루션이 필요합니다. 일부는 직접적인 대체가 있을 것입니다. 다른 것들은 사용자 정의 개발이 필요할 것입니다.
TYPO3에서의 일반적인 마이그레이션 경로
조직이 TYPO3를 떠날 때 일반적으로 어디로 가는지는 다음과 같습니다:
| 마이그레이션 대상 | 가장 적합한 경우 | 일반적인 타임라인 | 상대적 비용 |
|---|---|---|---|
| WordPress | 간단한 콘텐츠 사이트, 블로그, 소규모 사업 | 6-12주 | €€ |
| Headless CMS + Next.js | 성능 중심, 다중 채널 | 12-20주 | €€€ |
| Headless CMS + Astro | 콘텐츠 풍부, 정적 우선 사이트 | 10-16주 | €€-€€€ |
| Drupal | 복잡한 엔터프라이즈, 편집 워크플로우 | 14-24주 | €€€-€€€€ |
| Contentful/Sanity/Storyblok | API 우선, 현대 편집 환경 | 12-18주 | €€€ |
Headless 경로
이것이 우리가 가장 자주 권장하는 것이며, Social Animal에서 특화하는 것입니다. TYPO3에서 headless CMS(Contentful, Sanity 또는 Storyblok 같은)로 이동하고 현대 프런트엔드 프레임워크와 결합하면 양쪽 세계의 최고를 얻을 수 있습니다: 훌륭한 편집 환경 AND 최고 수준의 성능.
우리는 Next.js 및 Astro로 광범위하게 구축했으며, 둘 다 TYPO3 마이그레이션의 탁월한 대상입니다. Next.js는 동적 기능, 인증 또는 전자상거래가 필요할 때 올바른 선택입니다. Astro는 콘텐츠가 중요하고 가능한 빠른 페이지 로드를 원할 때 빛납니다.
WordPress 경로
내 말을 듣습니다. 한 전통 CMS에서 다른 전통 CMS로 이동하는 것은 측면 이동처럼 느껴집니다. 하지만 한번 들어보세요 -- WordPress는 거대한 생태계, 쉽게 구할 수 있는 개발자, 그리고 (WPGraphQL과 함께 headless CMS로 사용할 때) 실제로 현대 프런트엔드를 강화할 수 있습니다. 간단한 콘텐츠 요구가 있는 더 작은 사이트의 경우, 그것은 종종 가장 비용 효율적인 경로입니다.
Drupal 경로
당신의 TYPO3 사이트가 복잡한 콘텐츠 모델링, 다중 사이트 설정, 세분화된 권한 및 무거운 편집 워크플로우를 가지고 있다면, Drupal이 가장 자연스러운 맞춤입니다. 콘텐츠 모델링 패러다임은 충분히 유사하여 마이그레이션이 상대적으로 예측 가능합니다. 하지만 당신은 여전히 PHP 지역에 있으며, 많은 동일한 장기적 문제를 상속받고 있습니다.
아무도 경고하지 않는 기술적 문제
이것이 내 전투 흔적이 드러나는 곳입니다. 이것들은 TYPO3 마이그레이션 중에 팀을 놀라게 하는 것들입니다.
다국어 콘텐츠는 엉망입니다
TYPO3는 오버레이 레코드를 통해 번역을 처리합니다. 기본 언어 콘텐츠는 한 행에 있고, 번역은 같은 테이블의 연결된 레코드입니다. 이 "연결 모드" 대 "자유 모드" 번역 접근 방식은 대부분의 현대 CMS에서 깔끔하게 매핑되지 않으며, 이는 로케일 기반 변형이나 별도 콘텐츠 항목을 사용하는 경향이 있습니다.
당신의 사이트가 5개 이상의 언어를 가지고 있다면(유럽 엔터프라이즈에서는 일반적임), 콘텐츠 마이그레이션이 단일 언어 사이트보다 2-3배 더 오래 걸릴 것으로 예상하세요.
TYPO3의 워크스페이스 및 버전 관리
콘텐츠 스테이징 및 승인 워크플로우를 위해 TYPO3 Workspaces를 사용하는 경우, 대상 플랫폼에서 동등한 것을 찾아야 합니다. 대부분의 headless CMS는 어떤 형태의 초안/발행 워크플로우를 가지고 있지만, 세분화된 워크스페이스 기반 접근 방식을 복제하려면 신중한 계획이 필요합니다.
확장 관련 콘텐츠
news, cal, powermail 및 gridelements 같은 TYPO3 확장은 자체 데이터베이스 테이블에 자체 스키마를 가진 콘텐츠를 저장합니다. 표준 콘텐츠 추출은 이를 다루지 않을 것입니다 -- 확장 특정 마이그레이션 스크립트가 필요합니다.
TYPO3의 tx_news_domain_model_news 테이블에서 뉴스 레코드를 추출하는 간단한 예시:
import mysql.connector
import json
def extract_typo3_news(db_config):
conn = mysql.connector.connect(**db_config)
cursor = conn.cursor(dictionary=True)
query = """
SELECT
n.uid,
n.title,
n.teaser,
n.bodytext,
n.datetime,
n.path_segment,
n.sys_language_uid,
GROUP_CONCAT(c.title) as categories
FROM tx_news_domain_model_news n
LEFT JOIN sys_category_record_mm mm
ON mm.uid_foreign = n.uid
AND mm.tablenames = 'tx_news_domain_model_news'
LEFT JOIN sys_category c
ON c.uid = mm.uid_local
WHERE n.deleted = 0
AND n.hidden = 0
GROUP BY n.uid
ORDER BY n.datetime DESC
"""
cursor.execute(query)
records = cursor.fetchall()
# Transform to target CMS format
transformed = []
for record in records:
transformed.append({
'title': record['title'],
'slug': record['path_segment'],
'excerpt': record['teaser'],
'body': record['bodytext'], # Will need RTE cleanup
'publishedAt': record['datetime'].isoformat(),
'locale': 'de' if record['sys_language_uid'] == 0 else 'en',
'categories': record['categories'].split(',') if record['categories'] else []
})
return transformed
이것은 간소화되었습니다 -- 실제 추출 스크립트는 파일 참조, 관련 레코드, RTE 콘텐츠 정리(<link t3://page?uid=42> 같은 TYPO3 고유 링크 구문 제거) 및 워크스페이스 인식 쿼리를 처리해야 합니다.
RTE 콘텐츠 정리
TYPO3의 Rich Text Editor는 t3://page?uid=123 같은 내부 링크 참조 및 t3://file?uid=456 같은 파일 참조로 콘텐츠를 저장합니다. 마이그레이션 중에 이러한 각각은 실제 URL이나 자산 경로로 해결되어야 합니다. 큰 사이트의 경우, 이러한 것들이 수천 개 있을 수 있습니다.
// 예시: 마이그레이션된 콘텐츠에서 TYPO3 내부 링크 해결
function resolveTypo3Links(html, urlMap, fileMap) {
// 페이지 링크 대체
let resolved = html.replace(
/t3:\/\/page\?uid=(\d+)/g,
(match, uid) => urlMap[uid] || '/404'
);
// 파일 링크 대체
resolved = resolved.replace(
/t3:\/\/file\?uid=(\d+)/g,
(match, uid) => fileMap[uid] || ''
);
return resolved;
}
TYPO3 마이그레이션 에이전시 평가 방법
모든 에이전시가 동일하게 만들어지지 않습니다. 찾아야 할 것들은 다음과 같습니다:
그들은 TYPO3 내부를 알아야 합니다
이것은 당연해 보일 수 있지만, 많은 에이전시들이 프런트엔드를 보고 재창조하여 사이트를 마이그레이션하려고 할 것이며, 백엔드 데이터 모델을 실제로 이해하지는 않을 것입니다. 그들에게 물어보세요:
pages와tt_content의 차이를 설명할 수 있습니까?sys_file_reference가 어떻게 작동하는지 알고 있습니까?- 이전에 TYPO3 Workspaces를 다루어 본 적이 있습니까?
- TypoScript을 쓸 수 있습니까? (싫어하더라도, 이해해야 합니다.)
그들은 대상 플랫폼의 전문가여야 합니다
동일하게 중요합니다 -- 그들은 가는 곳에 대한 깊은 전문 지식이 필요합니다. "React를 배우고 있는" TYPO3 상점은 당신이 프런트엔드를 재구축하기를 원하는 사람이 아닙니다.
Social Animal에서, 우리의 핵심 전문 지식은 headless CMS 개발입니다. 우리는 매일 함께 구축하기 때문에 대상 플랫폼을 속속들이 알고 있습니다.
그들은 문서화된 마이그레이션 프로세스를 가져야 합니다
그들의 마이그레이션 방법론을 물어보세요. 그것은 다음을 다루어야 합니다:
- Discovery 및 감사
- 대상 플랫폼의 콘텐츠 모델링
- 데이터 추출 및 변환 스크립트
- URL 매핑 및 리디렉트 전략
- 프런트엔드 개발
- 콘텐츠 검증 및 QA
- SEO 검증
- 출시 및 모니터링
그들이 구체적인 내용과 함께 이 단계들을 당신에게 설명할 수 없다면, 그들은 즉흥적으로 하고 있는 것입니다.
위험한 신호
- "우리는 그냥 콘텐츠를 내보내고 가져올 거예요" -- 절대 그렇게 간단하지 않습니다
- SEO 보존에 대한 언급이 없음
- 발견 단계 없이 고정 가격 견적
- 특정 TYPO3 버전에 대한 경험 없음
- 이전 TYPO3 마이그레이션 프로젝트를 보여줄 수 없음
마이그레이션 타임라인 및 비용 예상
실제 숫자를 이야기해 봅시다. 이것들은 중간 규모 엔터프라이즈 사이트(500-2,000 페이지)에 대한 2025년 유럽 시장 요금에 기반합니다.
| 단계 | 기간 | 비용 범위 (EUR) |
|---|---|---|
| 발견 및 감사 | 2-4주 | €8,000-15,000 |
| 콘텐츠 모델링 및 전략 | 2-3주 | €6,000-12,000 |
| 데이터 마이그레이션 스크립트 | 3-6주 | €12,000-25,000 |
| 프런트엔드 개발 | 6-12주 | €25,000-60,000 |
| 통합 개발 | 2-6주 | €8,000-25,000 |
| QA 및 콘텐츠 검증 | 2-4주 | €6,000-15,000 |
| SEO 검증 및 출시 | 1-2주 | €4,000-8,000 |
| 합계 | 18-37주 | €69,000-160,000 |
이 숫자들은 사람들을 두렵게 합니다. 하지만 앞으로 3-5년 동안 TYPO3에 머물러 있을 비용과 비교해 보세요: 개발자 비용, 호스팅, 느린 개발 속도로 인한 놓친 기회. 마이그레이션은 보통 18-24개월 내에 스스로를 갚습니다.
당신의 상황에 따라 더 구체적인 견적을 위해, 저희에게 연락하세요이고 우리는 무료 초기 평가를 해드릴 것입니다.
마이그레이션 중 SEO 보존
이것은 마케팅 담당자를 밤새 깨게 하고, 당연히 그럴 만한 부분입니다. 어설픈 마이그레이션은 수년간의 SEO 투자를 파괴할 수 있습니다.
필수 불가결한 체크리스트
완전한 URL 인벤토리 -- Screaming Frog나 Sitebulk로 현재 사이트를 크롤합니다. 모든 URL, 상태 코드, 제목 태그, 메타 설명 및 정규 태그를 내보냅니다.
1:1 URL 매핑 -- 모든 이전 URL은 301 리디렉트를 통해 새 URL을 가리켜야 합니다. 예외는 없습니다.
페이지 상 SEO 요소 보존 -- 제목 태그, 메타 설명, 제목 구조, 이미지 alt 텍스트 및 구조화된 데이터는 모두 마이그레이션되어야 합니다.
내부 링크 감사 -- 콘텐츠의 모든 내부 링크는 리디렉트에 의존하지 않고 새 URL을 가리키도록 업데이트되어야 합니다.
XML 사이트맵 -- 즉시 새 사이트맵을 생성하고 Google Search Console에 제출합니다.
90일 동안 모니터링 -- 처음 2주 동안 Google Search Console을 매일 확인한 다음 3개월 동안 주간으로 확인합니다. 조기에 크롤 오류, 인덱싱 문제 및 순위 변동을 잡을 것입니다.
현실
완벽한 실행에도 불구하고, 마이그레이션 후 처음 2-4주에는 순위가 일시적으로 10-20% 하락할 것으로 예상하세요. Google은 재크롤 및 재평가할 시간이 필요합니다. 당신이 모든 것을 올바르게 했다면, 순위는 회복할 것이며 일반적으로 6-8주 이내에 개선되며, 특히 새 사이트가 더 빠른 경우에 그렇습니다.
사례 연구: 실제 마이그레이션의 모습
기존 프로젝트에 기반한 복합 예시를 살펴보겠습니다(기밀성을 위해 세부 사항은 변경됨).
상황: 독일 제조 회사, TYPO3 v9 사이트. 4개 언어(DE, EN, FR, IT)의 1,200 페이지. news 확장의 무거운 사용, 사용자 정의 제품 카탈로그 확장 및 리드 생성 양식을 위한 powermail. 편집 환경에 불만족하는 3명의 콘텐츠 편집자.
결정: Storyblok (headless CMS) + Next.js (프런트엔드)로 마이그레이션합니다.
무슨 일이 일어났는지:
발견 (3주): 전체 콘텐츠 모델을 감사했습니다, 14개의 독립된 콘텐츠 유형을 식별하고, 47개의 TYPO3 백엔드 레이아웃 및 콘텐츠 요소 구성을 매핑하고, 모든 통합을 문서화했습니다.
콘텐츠 모델링 (2주): Storyblok 콘텐츠 모델을 설계했습니다. 유사한 패턴을 통합하여 14개의 콘텐츠 유형을 9개로 축소했습니다. 편집자들이 Storyblok의 시각적 편집자에서 미리 볼 수 있는 시각적 컴포넌트 라이브러리를 생성했습니다.
데이터 마이그레이션 (5주): 모든 콘텐츠 테이블에 대한 Python 추출 스크립트를 구축했습니다. 가장 어려운 부분은? 제품 카탈로그 확장은 12개 테이블과 순환 참조가 있는 사용자 정의 데이터베이스 스키마를 사용했습니다. 우리는 그것만을 위해 헌신적인 ETL 파이프라인을 작성했습니다.
프런트엔드 (10주): Tailwind CSS를 사용하여 Next.js에서 전체 프런트엔드를 재구축했습니다. Lighthouse 점수는 평균 45(TYPO3)에서 94(Next.js)로 올라갔습니다. 모바일 성능이 극적으로 개선되었습니다.
QA (3주): 콘텐츠 편집자들은 모든 언어의 모든 페이지를 검증했습니다. 우리는 23개의 끊긴 내부 링크와 8개의 누락된 이미지 참조를 찾고 수정했습니다.
출시: 리디렉트 맵을 배포했습니다(언어당 1,200+ 항목). Search Console을 모니터링했습니다. 순위는 1주차에 12% 떨어졌으며, 4주차에 완전히 회복했으며, 8주차에 15% 개선되었습니다.
전체 기간: 24주. 전체 비용: €115,000. 호스팅 및 유지보수의 연간 절감액: €28,000. 편집자 만족도: 하늘을 찌릅니다.
FAQ
일반적인 TYPO3 마이그레이션은 얼마나 걸립니까? 중간 규모 사이트(500-2,000 페이지)의 경우, 출시에서 출시까지 4-9개월로 예상하세요. 가장 큰 변수는 언어 수, 사용자 정의 확장 및 통합입니다. 간단한 단일 언어 브로셔 사이트는 8-12주에 완료할 수 있습니다. 복잡한 워크플로우가 있는 대규모 다중 사이트 TYPO3 설치는 12+ 개월이 걸릴 수 있습니다.
TYPO3를 WordPress로 마이그레이션할 수 있습니까? 예, 그것이 가장 일반적인 마이그레이션 경로 중 하나이며, 특히 작은 조직의 경우입니다. WordPress는 훨씬 더 큰 개발자 생태계와 낮은 유지보수 비용을 가지고 있습니다. 하지만 마이그레이션이 TYPO3의 콘텐츠 요소 모델을 적절하게 처리하는지 확인하고 싶습니다 -- TYPO3의 구조화된 콘텐츠 접근 방식은 WordPress의 기본 블록 편집기보다 더 세분화되어 있습니다. 최고의 장기 아키텍처를 위해 현대 프런트엔드가 있는 WordPress를 headless CMS로 고려하세요.
마이그레이션 중에 Google 순위를 잃습니까? 처음 2-4주에는 10-20%의 임시 하락이 있을 가능성이 높습니다. 적절한 301 리디렉트 매핑, 보존된 메타 데이터 및 더 빠른 새 사이트로, 순위는 일반적으로 4-8주 내에 회복되며 종종 개선됩니다. 핵심은 완전한 URL 매핑 전략과 출시 후 Search Console의 밀접한 모니터링입니다.
TYPO3에서 마이그레이션하는 비용은 얼마입니까? 유럽 시장(2025년)에서, 간단한 사이트의 경우 €40,000-80,000, 다양한 언어, 사용자 정의 확장 및 통합이 있는 복잡한 엔터프라이즈 설치의 경우 €80,000-200,000 이상으로 예상하세요. 마이그레이션 투자의 ROI를 계산할 때 개발자 비용 및 호스팅의 연간 절감을 고려하세요 -- 대부분의 조직은 18-24개월 내에 마이그레이션 투자를 회수합니다. 더 구체적인 지침은 가격 책정 페이지를 확인하세요.
TYPO3를 업그레이드해야 합니까 아니면 다른 플랫폼으로 마이그레이션해야 합니까? TYPO3 v10 또는 v11에 있고 당신의 팀이 플랫폼에 만족한다면, v13 LTS로 업그레이드하는 것이 타당할 수 있습니다. 하지만 v8이나 v9에 있다면(둘 다 지원 종료됨), 업그레이드 노력은 전체 마이그레이션만큼입니다. 그리고 당신은 여전히 축소하는 개발자 풀과 높은 유지보수 비용을 다루게 될 것입니다. 대부분의 조직의 경우, 마이그레이션이 매우 오래된 버전에서 업그레이드하는 것보다 더 재정적으로 타당합니다.
마이그레이션 중 내 TYPO3 확장은 어떻게 됩니까?
모든 확장은 대상 플랫폼에서 동등한 솔루션이 필요합니다. news, powermail 및 solr 같은 인기 있는 확장은 대부분의 플랫폼에서 잘 확립된 대안을 가지고 있습니다. 사용자 정의 확장은 새 플랫폼에서 맞춤 개발이 필요합니다. 좋은 마이그레이션 에이전시는 발견 중에 모든 확장을 감사하고 각각에 대한 구체적인 대체 전략을 제안할 것입니다.
TYPO3에서 단계적 마이그레이션을 할 수 있습니까? 절대적으로, 그것은 종종 큰 사이트에 대한 현명한 접근입니다. TYPO3와 새 플랫폼을 나란히 실행하고 섹션을 점진적으로 마이그레이션할 수 있습니다. 이것은 특히 headless 아키텍처에서 실용적이며 역방향 프록시 규칙을 사용하여 다양한 섹션을 다양한 백엔드에서 제공할 수 있습니다. 위험을 감소시키지만 전체 타임라인을 연장하고 인프라 복잡성을 증가시킵니다.
마이그레이션 중 TYPO3의 다국어 콘텐츠를 어떻게 처리합니까? TYPO3의 번역 오버레이 시스템은 마이그레이션하기 가장 어려운 측면 중 하나입니다. 각 대상 플랫폼은 지역화를 다르게 처리합니다. Storyblok는 필드 수준 번역을 사용하고, Contentful은 로케일 기반 항목을 사용하며, Sanity는 문서 수준 번역을 사용합니다. 마이그레이션 에이전시는 TYPO3의 "연결" 및 "자유" 번역 모드를 모두 이해하고 당신의 사이트가 사용하는 특정 접근 방식을 처리하는 추출 스크립트를 설계해야 합니다. 다국어 사이트의 경우 여분의 시간을 예산으로 책정하세요 -- 그것은 항상 예상보다 더 복잡합니다.