העברת Bitrix24 On-Premise לענן: מדריך להעברת פורטל ו-CRM

אתה רוצה להתרחק מניהול שרת משלך, לצמצם את תשתית ה-IT ולהשתמש ביכולות ענן שאינן זמינות בגרסת ה-On-Premise. המעבר מ-On-Premise לענן כולל אילוץ מהותי: Bitrix24 אינה מספקת כלי ייבוא רשמי מהגרסה ה-boxed. העברת נתונים אפשרית רק דרך REST API — בכיוון ההפוך בהשוואה להגירה מהענן ל-box. במשך יותר מ-5 שנים השלמנו יותר מ-30 פרויקטים כאלה ואנחנו מכירים את כל המלכודות.

Bitrix24 בענן מציעה תכונות מובנות שאינן זמינות בגרסת ה-On-Premise: טלפוניה WebRTC, אפליקציה ניידת מלאה, עדכונים אוטומטיים. זה מפחית את העומס מצוות ה-IT ומצמצם את עלויות חומרת השרת ב-40-60%.

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

נתונים זמינים להעברה

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

מדוע מודולים מותאמים אישית הם הבעיה העיקרית

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

תהליך העברת נתוני CRM

הנתונים מיוצאים מהמערכת המקומית (on-premise) דרך REST API (הפועל באופן זהה בשתי הגרסאות) ונטענים לענן דרך אותו REST API. רצף הפעולות:

1. יצירת אפליקציית OAuth בפורטל הענן לצורך אימות בקשות.
2. העברת משתמשים — הזמנה ידנית דרך הממשק או שימוש ב-user.add (רק ב-On-Premise; API הענן מגביל הוספת משתמשים).
3. יצירה מחדש של ספריות: סטטוסי עסקאות (crm.status.add), משפכים (crm.dealcategory.add), שדות משתמש (crm.userfield.add).
4. העברת נתוני CRM: חברות → אנשי קשר → לידים → עסקאות תוך שמירה על מיפוי מזהים.
5. העברת קבצי Disk דרך disk.folder.uploadfile.

סקריפט ההעברה פועל עם שני לקוחות API בו-זמנית: אחד מחובר למערכת המקומית (המקור), והשני לענן (היעד). התיעוד הרשמי של Bitrix24 Bitrix24 REST API documentation מגביל את תדירות הבקשות ל-API הענן באופן מחמיר יותר מאשר ל-API המקומי.

בתעריף 'Team' — 2 בקשות בשנייה, בתעריף 'Company' — עד 200. עבור נפחים גדולים, אנו מיישמים הגבלת קצב:

class RateLimiter {
    private float $lastRequest = 0;
    private float $minInterval; // seconds between requests

    public function wait(): void {
        $elapsed = microtime(true) - $this->lastRequest;
        if ($elapsed < $this->minInterval) {
            usleep((int)(($this->minInterval - $elapsed) * 1_000_000));
        }
        $this->lastRequest = microtime(true);
    }
}

מהן מגבלות API וכיצד לעקוף אותן?

מגבלות API הן גורם מרכזי בתכנון. לפי תיעוד Bitrix24 REST API, המגבלות נמוכות יותר בתעריפי הענן. ה-RateLimiter שלעיל הוא פתרון סטנדרטי. בפועל, אנו משתמשים במרווח זמן הניתן להגדרה ובתור משימות כדי להישאר בגבולות המגבלות. לדוגמה, תעריף 'Company' מהיר עד פי 100 מתעריף 'Team' להעברת נתונים.

Bitrix24 בענן מפחית את העלות הכוללת של הבעלות (TCO) פי 2–3 בהשוואה לגרסה המקומית על ידי ביטול חומרת השרת והניהול שלה. המשמעות היא חיסכון בעלות המחושבת לאחר ביקורת בהתאם לגודל החברה.

מה כלול בעבודה?

• ביקורת של התצורה הנוכחית: מיפוי מודולים, שדות משתמש, תהליכים עסקיים.
• הסכמה על תוכנית ההעברה: אילו נתונים להעביר, מה לשכתב.
• פיתוח סקריפטים להעברה: עם הגבלת קצב ומיפוי מזהים.
• הרצת בדיקה: על עותק של נתונים, בדיקת שלמות.
• עבודה במקביל: 2–4 שבועות של שימוש משותף ב-on-premise ובענן.
• הדרכת עובדים: עבודה עם הממשק החדש ואפליקציות REST.
• תמיכה לאחר ההעברה: שבועיים לאחר המעבר.

צ'קליסט לפני ההעברה:

• לבדוק אילו מודולים של PHP בשימוש — הם לא יועברו.
• לקבוע את תעריף הענן: הוא משפיע על מגבלות ה-API.
• למנות אחראי על מיפוי מזהי המשתמשים.
• ליצור אפליקציית OAuth בפורטל הענן.
• להכין את הסביבה לעבודה במקביל.

תקופת פעולה במקביל

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

לוחות זמנים אופייניים

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