Usługi CMS najczęściej działają w dwóch niezależnych modelach. Model pierwszy czyli CMS online’owy jest rozwiązaniem, w którym logika aplikacyjna serwisu jest już sama w sobie interfejsem systemu CMS. Oznacza to, że użytkownik, który ogląda nasz gotowy serwis w gruncie rzeczy widzi serwis całkowicie dynamiczny (nawet jeśli z pozoru nic na to nie wskazuje) co w konsekwencji oznacza, że każdy element serwisu wyświetlony użytkownikowi musiał zostać niejako wygenerowany w locie (dotyczy to np. jego pozycji na serwisie, zawartości). Dla niewielkich serwisów jest to rozwiązanie wygodne i optymalne, jednak przy sporej oglądalności, dynamiczne tworzenie całego wyglądu serwisu od zera oznacza spory narzut na wydajność całego rozwiązania i bardzo często prowadzi do problemów z działaniem (najczęściej tzw. „wolne ładownie”). Takie online’owe CMS’y są najczęściej spotykanymi rozwiązaniami oferowanymi na rynku (zarówno przez dostawców hostignowych jak i w formie gotowego oprogramowania OpenSource czy komercyjnego), są również najczęściej rozwiązaniem najtańszym.

Alternatywnym rozwiązaniem jest tzw. CMS offline’owy, architektura tego rozwiązania przewiduje fizyczne oddzielenie warstwy logiki aplikacyjnej (interfejsu do wprowadzania zmian) od serwisu (strony) który ogląda użytkownik. Taki model pozwala łatwo i dynamicznie skalować wydajność serwisu, a zmiany wprowadzone przez redaktorów nie mają bezpośredniego wpływu na zawartość widzianą przez użytkowników. W jaki zatem sposób zmodyfikowane pojawiają się na publicznej i produkcyjnej wersji serwisu ?

Otóż kluczem jest tzw. Staging, publikacja asynchroniczna oraz ustatycznianie serwisów. Staging pozwala na budowę etapów publikacji serwisów. Publikacja asynchroniczna pozwala na publikowanie zmian w grupach (wiele zmian na raz, zamiast każda zmiana osobno). Ustatycznianie z kolei pozwala na wygenerowanie statycznych plików serwisu (popularnych plików .html .js) i publikacje ich w takiej formie do części produkcyjnej.

Oczywiście ktoś może zauważyć, że skoro serwis został ustatyczniony, to jego zawartość będzie nudna dla odbiorcy czy trudno będzie wprowadzić zmiany. W rzeczywistości jednak ustatycznianie w tym rozumieniu pozwala na uniknięcie generowania struktury serwisu w locie (de facto CMS online’owy też ostatecznie wygeneruje statyczną zawartość – zrobi to jednak osobno dla każdego użytkownika) i zrobienie tego jeden raz dla wszystkich. Nie ma to wpływu na obiekty osadzone na stronie, takie jak flash, javascript, czy inne, zatem dynamizacja serwisu pozostanie zachowana. Co w takim razie z elementami personalizacji serwisu (logowanie, etc) – otóż zarówno w przypadku CMS’ów online’owych jak i offline’owych takie elementy muszą być całkowicie pisane od nowa i przystosowane do konkretnego serwisu, nie powinny mieć zatem wpływu na wybór konkretnego rozwiązania CMS.

Staging pozwala natomiast utworzyć strefy publikacji. Pozwala to na wczesnym etapie wyłapać ewentualne błędy, przetestować funkcjonalność czy nawet wykonać testy obciążeniowe bez wpływu na docelowe środowisko produkcyjne. Najczęściej tworzone są 3 strefy. Pierwsza tzw. developerska pozwala ocenić integrację serwisu z aplikacjami oraz przetestować jego działanie, pozwala również na różne próby programistyczne czy wizerunkowe. Druga tzw. testowa jest ostatecznym wizerunkiem serwisu (tzw. preprodukcja). Trzecia to już rzeczywisty system produkcyjny. Czasami wprowadzą się dodatkową strefę pomiędzy testową i produkcyjną (tzw. beta) – najczęściej służy ona ostatecznej weryfikacji (warto zaznaczyć, że powinna być umieszczona już na serwerach produkcyjnych lub im bliźniaczych pod kątem sprzętu i konfiguracji systemu). Staging jest ogólnie uznaną metodą developmentu serwisów webowych (Więcej na wikipedii)

Proces publikacji rozpoczyna się w momencie zakończenia pracy w CMS’ie offline’owym i najczęściej naciśnięcia linku ‘publikuj’. W tym momencie CMS wykona trzy operacje:

Od tego momentu w strefie developerskiej mamy wierną kopię tego co zostało utworzone w CMS’ie. W tym momencie najczęściej programiści dysponują już odpowiednim materiałem koniecznym do połączenia z aplikacjami właściwymi dla konkretnego serwisu. Po wprowadzeniu zmian przez programistów następuje proces publikacji całego serwisu (łącznie z aplikacjami) do środowiska testowego.

W tym momencie odpowiedzialność za dalszy proces zostaje przeniesiona na osobę posiadającą uprawnienia do publikacji na część produkcyjną (dobrą praktyką jest aby takich osób było jak najmniej, optymalnie jedna). Osoba taka rozpoczyna proces weryfikacji działania serwisu w strefie testowej np. angażując testerów bądź przy niewielkich serwisach sprawdzając działanie serwisu samodzielnie. Po akceptacji działania serwisu w strefie testów, uruchomiony zostaje moduł odpowiedzialny za przeniesienie całości na system produkcyjny. Schemat procesu publikacji:  

Istotną cechą opisanego powyżej rozwiązania jest pełna skalowalność i dostosowanie do potrzeb serwisu. Wszystkie operacje opisane powyżej mogą być bardzo łatwo przeprowadzone przez jedną osobę posiadającą uprawnienia ról edytora, testera i publikacji jak i złożony zespół kilkudziesięciu osób w których każda odpowiada za inną część serwisu.

Jednym z offline’owych CMS’ów jest ogólnie uznany na świecie RedDot CMS.

Obecnie znajduje się on w ofercie dla naszych klientów jako podstawowy mechanizm edycji serwisów. Usługa jest świadczona w modelu SaaS, podstawową jednostką rozliczeniową jest liczba kont w systemie oraz pula przydzielonego miejsca na dyskach.

Naistoniejsze cechy RedDot CMS to:

1. Łatwość użytkowania. Przekazanie edycji określonych obszarów projektu internetowego osobom najbardziej kompetentnym pod względem merytorycznym z reguły wymaga szkoleń technicznych. Szkolenia takie zazwyczaj są kosztowne i pochłaniają czas. Technologia RedDot SmartEdit pozwala dowolnym użytkownikom samodzielnie edytować każdy element projektu. Mogą oni tworzyć nową zawartość lub też użyć gotowych treści z innych dokumentów, takich jak np. MS Office, przeciągając je myszką do edytowanego elementu. Wprowadzane zmiany są natychmiastowe, a redagujący w trakcie pracy widzą stronę internetową doładnie, tak jak będzie wyglądała po opublikowaniu nowych treści w sieci.

2. Szybki dostęp. Stosując rozwiązania RedDot, nie ma konieczności instalowania oprogramowania dla każdego użytkownika. Edycja odbywa się w przeglądarce internetowej, która jest dostępna na praktycznie każdym komputerze. Podstawą cechą rozwiązań RedDot jest wygodna praca z oprogramowaniem. Jest ona na tyle intuicyjna, że użytkownicy z niewielkim doświadczeniem w pracy z komputerem mogą samodzielnie redagować treści po krótkim szkoleniu.

3. Prosty w administrowaniu. Za pomocą technologii SmartEdit użytkownicy mogą dokonywać zmian jedynie w ramach udostępnionych im obszarów. Użytkownicy mają nadawane indywidualne uprawnienia w module administracyjnym. RedDot CMS wspiera LDAP oraz infrastrukturę ActiveDirectory , co pozwala wykorzystać istniejącą strukturę uprawnień. Dodatkowo system wspiera proces uprawnień do publikacji, zatwierdzania i korygowania zawartości, który może być indywidualnie konfigurowany za pomocą schematu przepływu pracy (workflow).