בדקו קודם מה פועל ומה דחוף

פתחו את האתר הציבורי ובדקו עמוד שירות, פרטי קשר ודרך פנייה. שלחו בדיקה מסומנת אם יש טופס ובקשו אישור קבלה. בדקו גם אם הדואר העסקי פעיל ואם יש הודעות על חידוש או חיוב קרוב. אתר שאינו ניתן לעריכה אך עובד דורש טיפול שונה מאתר שכבר אינו זמין. כתבו את המצב בפועל בלי להסיק עדיין מה הסיבה.

קבעו סדר עדיפויות לפי פגיעה בעבודה: אתר לא זמין, דואר שאינו מגיע, פניות שאובדות או תוכן שחייב תיקון. אל תבטלו את האחסון כדי להפסיק חיוב לפני שיודעים מה נמצא בו. ייתכן שהוא קשור לרכיבים נוספים. אם התקלה המרכזית היא פנייה שלא נמסרת, השתמשו במסלול בדיקת טופס כדי לאסוף ראיות, ובמקביל המשיכו למפות את ההרשאות הדרושות לטיפול.

הדומיין הוא רכיב נפרד מהאתר

הדומיין הוא שם הכתובת הרשום אצל רשם, ואינו זהה לקבצי האתר או לחשבון האחסון. חפשו מסמכי רכישה, חשבוניות והודעות חידוש כדי לזהות את הרשם ואת החשבון הרלוונטי. בדקו מי מופיע כגורם המוסמך ומי מקבל הודעות. אל תסיקו שבעלות על לוגו או תשלום לבונה האתר מוכיחים לבדם גישה לחשבון הדומיין; צריך לברר את הרישום וההרשאות בפועל.

אם אין גישה, פנו לרשם דרך ערוץ התמיכה הרשמי ושאלו מה נדרש להסדרת חשבון או זכאות לפעולה. תהליכים וכללים משתנים בין סיומות ורשמים, ולכן אין הוראה אחת שמתאימה לכל דומיין. הנחיות ICANN יכולות לסייע בהבנת העברה של דומיינים שבתחום מדיניותה, אך אינן תחליף לכללים של רשם מקומי או סיומת מדינתית. אין לנסות לעקוף חשבון של אדם אחר או להשתמש בהרשאה שלא ניתנה לכם.

האחסון והדואר דורשים מיפוי משלהם

זהו היכן האתר מתארח ומי מחזיק בחשבון. ייתכן שהעסק משלם ישירות, וייתכן שהשירות נמצא בתוך חשבון של הספק. שאלו אילו רכיבים כלולים: קבצים, מסד נתונים, דואר, תעודות וחיבורים. אל תניחו שהעברת הדומיין מעבירה גם את התוכן או את תיבות הדואר. אלו פעולות שונות שצריכות תכנון לפי המערכת שבה העסק משתמש.

אספו הודעות חיוב ושמות שירותים בתיק מסודר, בלי להעתיק סיסמאות למסמך פתוח. אם ספק האחסון יכול לסייע, הוא יפעל לפי בדיקת הזכאות שלו. מסרו מידע נדרש בערוץ הרשמי והימנעו משליחת מסמכים לכל אדם שמציע פתרון מהיר. כתבו מה ידוע על כל רכיב ומה דורש בירור, כדי שהספק החדש לא יבנה תוכנית מעבר על הנחה שגויה לגבי גישה.

מערכת ניהול, קוד ותוכן אינם אותו דבר

גישה לעורך תוכן עשויה לאפשר שינוי טקסטים אך לא הורדת קוד או גיבוי מלא. גישה לקוד אינה בהכרח כוללת מסד נתונים, תמונות או הגדרות חיבור. רשמו אילו פעולות אפשר לבצע בכל חשבון: לערוך, לייצא, להוריד, לפרסם או לנהל משתמשים. התיאור הזה מועיל יותר מהמילה יש גישה, שאינה אומרת אם אפשר לשחזר את האתר או להעבירו.

אספו גם חומרי מקור שבשליטת העסק: טקסטים, תמונות, לוגו, מסמכי אפיון וקבצים שנמסרו במהלך הפרויקט. בדקו מה מותר להשתמש בו לפי ההסכמות והרישיונות הקיימים. אין להניח שכל רכיב שנראה באתר ניתן להעתקה חופשית לסביבה אחרת. כאשר יש מחלוקת על זכויות, יש לברר אותה בערוץ מתאים; מיפוי טכני אינו קובע בעלות משפטית ואינו מחליף בדיקה של ההסכם.

גיבוי נבחן לפי יכולת שחזור

שאלו מתי נוצר הגיבוי, מה הוא כולל והיכן נשמר. קובץ בודד עם שם אתר אינו הוכחה שהוא מספיק להקמה מחדש. בקשו מאיש מקצוע לבדוק שחזור בסביבה מתאימה לפני שמשנים את האתר הפעיל. הבדיקה צריכה לוודא שתוכן, קבצים ופונקציות חיוניות זמינים, ושאין תלות שנשכחה בחשבון של הספק הקודם.

אם אין גיבוי מלא, תעדו מה כן אפשר לשמר בהרשאה קיימת. אפשר לשמור עותקים של חומרי העסק ושל העמודים הציבוריים לצורך מיפוי, אך צילום עמוד אינו תחליף לאתר מתפקד. אין צורך להבטיח שחזור מושלם לפני שנבדקה התשתית. ההחלטה אם לשקם או לבנות מחדש תגיע לאחר שמבינים מה קיים, מה נגיש ומה יידרש ליצור מחדש.

פנו לספק הקודם עם רשימת מסירה קונקרטית

אם קיימת דרך תקשורת, שלחו בקשה עניינית שמפרטת את הנכסים: פרטי רשם הדומיין, אחסון, חשבון ניהול, גיבוי, קוד וחיבורים רלוונטיים. בקשו הזמנת משתמש או העברת הרשאה במקום סיסמה אישית. ציינו מי מטעם העסק מוסמך לקבל את החומר ואיך מאשרים שהמסירה הושלמה. בקשה מפורטת מפחיתה תשובות חלקיות כמו הכול נמצא באתר.

שמרו תיעוד של הבקשה והתשובות. אם הספק אינו עונה, התיעוד יכול לעזור להבין מה כבר נעשה ולפנות לתמיכות המתאימות. אל תפרסמו האשמות או פרטי גישה כחלק מניסיון לזרז תגובה. המטרה כאן היא המשכיות טכנית ומסירה מסודרת. אם קיימת מחלוקת כספית או חוזית, יש לטפל בה בנפרד מבלי לבצע שינויים בלתי הפיכים בנכס שאינכם מבינים עדיין.

עצרו לפני שינוי שמשפיע על שירות חי

שינוי הגדרות דומיין או שרתי שמות עשוי להשפיע על האתר ועל שירותים תלויים, ולכן צריך לדעת אילו רשומות וחיבורים קיימים לפני הפעולה. ביטול חשבון אחסון עלול להסיר חומר שטרם גובה. החלפת מפתחות חיבור יכולה להפסיק טופס או שירות חיצוני. אין צורך שבעל העסק יבצע את השינויים בעצמו; עליו לדרוש תוכנית, גיבוי ובדיקות חזרה.

לפני מעבר הגדירו מה ייבדק מיד אחריו: כתובת האתר, עמודים חשובים, דואר נכנס ויוצא, טופס ופונקציות שהעסק משתמש בהן. קבעו גם מי יכול לחזור למצב קודם אם מופיעה תקלה, ככל שהתשתית מאפשרת זאת. פעולה נראית קטנה במסך ניהול יכולה להשפיע על כמה שירותים. לכן מסמך תלות קצר חשוב יותר מהרצון לסיים את ההעברה במהירות.

הכינו תיק מסירה לספק הבא

בתיק המסירה צריכה להיות טבלת רכיב, ספק, חשבון מוסמך, מצב גישה, חומר זמין ופעולה נדרשת. ציינו מה עובד כיום ומה אינו עובד, והוסיפו רשימת כתובות ותוכן שצריך לשמר. אל תשלחו סיסמאות באותה טבלה; השתמשו בדרך מסירה מתאימה והרשאות אישיות ככל שניתן. הפרידו בין מידע שהספק צריך כדי להעריך את המצב לבין הרשאה שהוא צריך רק לאחר הגדרת העבודה. לפני בחירת הספק הבא, השוו את ההצעה לפי רשימת הבדיקה להצעת מחיר לאתר, וודאו שהיא מגדירה גם מסירה, הרשאות ותחזוקה.

אם גם פרופיל העסק בגוגל נוהל בידי אותו ספק, טפלו בו בנפרד לפי החזרת גישה לפרופיל העסק. חשבון אתר אינו מקנה הרשאה לפרופיל, ולהפך. תיק מסירה טוב אינו חייב להיות ארוך. הוא צריך לאפשר לאדם חדש להבין אילו פעולות אפשריות, מה חסר ובאיזה סדר נכון לבדוק אותן בלי לנחש.

בחרו שיקום או בנייה רק אחרי המיפוי

לאחר שברור מה בשליטת העסק, אפשר לבחון תיקון, שיפור בשלבים או החלפה לפי ההחלטה אם לשפר אתר או לבנות מחדש. ייתכן שהאתר תקין ורק נדרש ספק תחזוקה חדש. ייתכן שחלק מהתשתית אינו נגיש וצריך לתכנן חלופה. ההמלצה צריכה להתייחס לממצאים ולחומר שניתן לשמר, ולא להניח שכל ניתוק מספק מחייב התחלה מאפס.

אפשר להעביר לטומוקה את תיק המצב במסגרת בניית אתרים ושיקום נוכחות קיימת. הגדירו את התוצר הראשון כמפת גישה ותוכנית עבודה, ורק אחר כך היקף ביצוע. בסיום המסירה ודאו שהעסק יודע מי מחזיק בכל רכיב, היכן נשמר גיבוי ומי מוסמך לאשר שינויים. זה הבסיס להמשך עבודה גם כאשר ספק או עובד מתחלפים בעתיד.

TumokaPLAN / BUILD / GROW
מפת שליטה לפני מעבר ספק
  1. דומיין ורשם
  2. אחסון ודואר
  3. מערכת, קוד ותוכן
  4. גיבוי שנבדק
  5. הרשאות ותוכנית מסירה

פועלים בהרשאות קיימות ובערוצי ספק רשמיים לפני שינוי שירות חי.

מקורות להעמקה

ICANN: שאלות על העברת דומיין, בכפוף לתחולת המדיניות